ECDHE key exchange for server authentication and a key server

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.

BACKGROUND

Technical Field

The present systems and methods relate to conducting an ephemeral elliptic curve Diffie Hellman key exchange (ECDHE) with authentication and multiple parties, and more particularly to communications between a computing device, a server, and a key server over a network in order for the computing device and the server to mutually derive a symmetric ciphering key with authentication of the server.

Description of Related Art

The use of elliptic curve cryptography (ECC) for computing devices has expanded over the past decade and is also expected to continue to grow. Many applications use or propose using ephemeral elliptic curve Diffie Hellman (ECDHE) key exchanges in order to derive a symmetric ciphering key. Prominent examples today include embedded universal integrated circuit cards (eUICCs) also known as embedded SIMs, Transport Layer Security (TLS) version 1.3 from the Internet Engineering Task Force (IETF), and the Device Provisioning Protocol (DPP) from the WiFi Alliance™. Other examples are expected in the future as well, such as the use of ECDHE in order to protect the Subscription Permanent Identifier (SUPI) for 5G mobile networks, where the SUPI is equivalent to an International Mobile Subscriber Identity (IMSI). ECDHE can be considered a subset of elliptic curve Diffie-Hellman key exchanges (ECDH), where ECDHE key exchanges use at least one ephemeral on short-term elliptic curve PKI key pair. Applications use ECDHE key exchanges in order for two nodes to mutually derive a symmetric ciphering key and a message authentication code (MAC) key using a key derivation function. The symmetric ciphering key can subsequently be used with a symmetric ciphering algorithm such as the Advanced Encryption Standard (AES) and the MAC key can be used to verify message integrity. In this manner, secure communication can be established between two nodes.

ECDHE key exchanges depend on a first node deriving a first ephemeral private and public key pair and a second node deriving or using a second private and public key, where the public key infrastructure (PKI) keys use a common elliptic curve. The elliptic curve can be specified in parameters that define a named curve such as secp256r1 (p256), secp256k1, secp385r1, etc., and many other possibilities exist as well. ECDHE key exchanges have multiple benefits over older generation technology such as Diffie Hellman key exchanges. With ECDHE, elliptic curve cryptography can be utilized with shorter keys and faster processing times compared to previous technology, for the equivalent level of security or bit length of keys. For example, a 256 bit ECC PKI key pair can be used to obtain a comparable level of security as that obtained from using a 3072 bit RSA based PKI key pair. Calculation or processing time for conducting an ECDHE key exchange can also be faster than a traditional Diffie Hellman key exchange for the same level of security, as defined by the resulting key length of a derived shared secret from the key exchange.

Although the use of ECDHE key exchanges is growing rapidly, improvements can be made for ECDHE key exchanges in order to further enhance security and also leverage existing keys that may be recorded by the nodes participating in an ECDHE key exchange. As one example, an ECDHE key exchange as contemplated for (a) the exemplary applications and standards from two paragraphs above do not normally (b) provide authentication of either node. Separate steps than an ECDHE key exchange have to be conducted in order to authenticate endpoints, such as using an elliptic curve digital signature algorithm (ECDSA) with static or long-term ECC PKI keys recorded by the nodes. ECDSA algorithms also have challenges, where the reuse of a value k for two different signatures can reveal the private key. As another example and related to the authentication issue above, an ECDHE is susceptible to “man in the middle” attacks, where an intermediate node or different node than the intended node can perform the ECDHE key exchange instead of the intended node. Thus, although ECDHE can securely establish a symmetric ciphering key for confidentiality of data communications, the confidentiality could be established with a party or node that is not the intended recipient of the confidential communications. Consequently, a need exists in the art for the intended two nodes for confidential communications to use an ECDHE key exchange in a manner where at least one of the two nodes can be authenticated.

A primary goal of ECDHE key exchanges is also to obtain forward secrecy, where an ECDHE key exchange can periodically be re-conducted in order to rotate or re-establish a new symmetric ciphering key. In this manner, if a private key is compromised then only the subset of historical data encrypted using the compromised private key is subject to decryption, and other communications using a different private key can remain secured. An authenticated ECDH key exchange can be conducted using at least one static PKI key pair (e.g. not an ephemeral key exchange with ephemeral PKI keys), but without the benefits of forward secrecy. A need exists in the art where two parties can conduct an authenticated ECDHE key exchange (e.g. by using ephemeral PKI keys) in order to obtain the benefits of forward secrecy.

The use of ECDH key exchanges (e.g. with at least one static PKI key pair) is also subject to greater security risks over time, where repeated use of one static PKI key pair is subject to cryptographic analysis and “leakage” of equivalent bits of security over time. Further, the use of ECDH key exchanges with one static PKI key pair and one ephemeral PKI key pair is more subject to risks of attacks from specifically chosen ephemeral PKI keys, such as ephemeral public keys that are either (i) not on the curve or (ii) specifically selected to expose information about the static private key. Thus, (a) repeated use of ECDHE key exchanges over time with different ephemeral PKI keys, compared to (b) using an ECDH key exchange with one static PKI key pair will result in greater security regarding confidentiality of communications. A need exists in the art where the greater security of ECDHE key exchanges can be obtained while also using static ECC PKI keys recorded by at least one of the nodes deriving a symmetric ciphering key using the ECDHE key exchange.

Many applications or new standards such as TLS version 1.3, DPP version 1.0 and 5G network standards from the 3rdGeneration Partnership Project (3GPP) implement ECDHE key exchanges in order to quickly establish confidentiality early in the communications between two nodes. As noted above, a traditional ECDHE key exchange establishes confidentiality without authentication, and authentication must be obtained through other means, such as ECDSA or DSA with certificate verification, message digest, etc. However, the nodes participating in communications with the above standards typically have access to other, secure and previously recorded PKI keys besides the ephemeral PKI keys derived in order to conduct the ECDHE key exchange. A need exists in the art for a node to use the previously recorded PKI keys for (a) a new ECDHE key exchange in order to establish an authenticated key exchange without (b) the risks of ECDH key exchanges for static PKI keys as discussed above.

In addition, a device seeking to establish secured communication with a server may not be able to efficiently or securely verify a full certificate chain for a certificate from a server or a network, due to limitations such as lack of Internet connectivity for the device, lack of global date and time to properly check certificate revocation, incompatible parameters for verifying signatures from intermediate certificate authorities, etc. A need exists in the art for a device to use a previously recorded public key for a server or a network in order to include the public key in an authenticated ECDHE key exchange such that communications with a server can be secured without a separate requirement for full certificate verification through all intermediate root certificates to a root certificate stored in the device.

Solutions have been proposed in the art for an authenticated Diffie-Hellman or elliptic curve Diffie-Hellman key exchange using ephemeral keys and static keys. Blake-Wilson et al in the paper “Key Agreement Protocols and their Security Analysis”, which is herein incorporated by reference, propose the use of both long-term static keys and short-term ephemeral keys with a DH key exchange in order to conduct the key exchange in an authenticated manner in order to address some needs in the art mentioned above. Likewise, the Internet Engineering Task Force (IETF) proposes the use of elliptic curve ephemeral and static PKI keys in the “Request for Comments” (RFC) 5753 document “Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)”, which is also hereby incorporated by reference.

However, the methods described for Blake-Wilson, RFC 5753, and related systems depend on (a) the recipient/responder of an ephemeral ECC public key from a sender/initiator to (b) also to record or operate with the static private ECC key corresponding to the static public key recorded by the sender. This can reduce scalability of a system with (i) a plurality of senders/initiators and (ii) a plurality of recipients/responders receiving an ephemeral ECC public keys for ECDHE key exchanges, since each recipient/responder also needs to record and operate on the static ECC private key corresponding to the static ECC public key recorded by the sender/initiator. The overall security of a system can be decreased for a system of potentially millions of devices and several servers, where the servers need to record server static private ECC keys corresponding to server static public ECC keys recorded by devices. A need exists in the art for (a) a recipient/responder to support authenticated ephemeral ECDH key exchanges without (b) the recipient/responder also recording the static ECC private key corresponding to the static ECC public key recorded by the sender/initiator.

Many other examples exist as well for needs in the art to conduct an ECDHE key exchange in a secure manner where at least one of the nodes can be authenticated, and the above are examples are just a few and intended to be illustrative instead of limiting.

SUMMARY

Methods and systems are provided for a server to conduct an ephemeral elliptic curve Diffie-Hellman key exchange (ECDHE) with a device and a key server. The device and the server can record and operate a set of compatible values and algorithms for a key pair generation algorithm, an ECDH key exchange algorithm, a key derivation function, a symmetric ciphering algorithm, and a random number generator, and a set of cryptographic parameters. The device can comprise a computing device with a network interface to communicate with the server via an IP network. The device can comprise a transducer device for operating a transducer and communicating the transducer data with the server via secured communications. The device can comprise a device for “the Internet of Things”, a mobile phone, a tracking device, a security system, a module, or similar devices. The server can comprise a computing device with a network interface to communicate with the device via the IP network and the key server via a private network. The device can record a network static public key and a domain name service (DNS) name or uniform resource locator (URL) for the server. The key server can record the network static private key. The server can record and operate a server database. The device can be one of a plurality of different devices communicating with the server.

Before distribution to an end user of the computing device, a device manufacturer or a device distributor or a device owner could record a set of data in nonvolatile memory for the device. In addition to regular operating data and programs for the device, such as an operating system and a transducer driver, the data recorded in device before distribution could include (i) a network static public key, (ii) a set of cryptographic parameters associated with the network static public key, and (iii) a device identity for the computing device. For a first exemplary embodiment, the network static public key can be unique for the device and not shared with other devices. For a second exemplary embodiment, the network static public key can be shared across a set of devices and thus the network static public key would not be uniquely recorded in an individual device, but the network static public key could be uniquely recorded in a set of devices.

After power up and/or connecting with the IP network, the device can use the random number generator, the cryptographic parameters, and the key pair generation algorithm to derive a device ephemeral private key and a device ephemeral public key. The device can send the device ephemeral public key and the associated set of cryptographic parameters to the server in a first message using the DNS name or a URL for the server. The device can also optionally send a device identity or a secure hash value for the network static public key to the server, in order for the server to identify the device or set of devices. In some exemplary embodiments, the identity of the device and also the secure hash value can be omitted from the first message and the server identifies the group of devices by a particular IP address and port number and/or URL and/or DNS name used by the server and receiving data from devices. In other words, without identifying data, (X) a subset of devices sending data (i) to the server where (ii) the server uses a particular name, URL, or IP address and/or port number can be identified by (Y) the server receiving data from the devices using the IP address and port number and/or URL and/or DNS name.

The server can receive the first message and process the first. The server can use the received set of cryptographic parameters to conduct an ECC point validation step to verify that the received ECC public key comprises a point on a named curve specified by the set of cryptographic parameters. The server can record the name or URL for a key server and communicate with the key server through a private network or a secured session over a public network such as the Internet. The server can establish a secure session with the key server. The server can (a) select the key server for the device using identifying information from the first message and then (b) forward the device ephemeral public key in a second message to the key server after the validation step. The second message can also include the set of cryptographic parameters. The identifying information from the first message for the device could comprise any of (i) an optional identity of the device in the first message, (ii) an optional secure hash value for the network static public key in the first message, (iii) the use of a particular set of cryptographic parameters in the first message, where the set of cryptographic parameters are associated with a particular key server, or (iv) the server can operate such that the use of a particular URL or IP address and port number is mapped to a particular key server.

The server can use a random number generator and a key pair generation algorithm and the set of cryptographic parameters to derive a random number for a server ephemeral private key and then use the server ephemeral private key to generate a server ephemeral public key. The server can conduct a first elliptic curve Diffie-Hellman key exchange (ECDH) using (i) the derived server ephemeral private key and received device ephemeral public key and (ii) the set of cryptographic parameters in order to derive a first shared secret. The server can also operate and record a key derivation function and a symmetric ciphering algorithm. The server can operate or be associated with a server database in order to record data for the server communicating with a plurality of different devices, such that different keys for different devices could be tracked by the server. In exemplary embodiments the first message is received with a random number generated by the device and also a source IP address and port number, and the server records the random number and the source IP address and port number for the first message in the server database.

The key server can receive the second message from the server over the secure connection. The second message can include the device ephemeral public key and the set of cryptographic parameters. For embodiments where the first message includes identifying information for the device (e.g. any of (i) through (iv) in the above paragraph), then the second message to the key server can also include the identifying information for the device. The key server can select or read the network static private key using the second message received from the server (including possibly identifying information of the device such as, but not limited to, a secure hash value for the network static public key, to select a specific network static private key for the device). The key server can conduct a second ECDH key exchange using (i) the selected network static private key for the device and the received device ephemeral public key and (ii) the set of cryptographic parameters in order to derive a second shared secret. The key server can send a response to the second message in the form of a third message to the server, where the third message includes the derived second shared secret.

The server can receive the derived second shared secret from the key server in the third message. The third message can also include identifying information such that the server can track which of the devices the third message from the key server is associated with. The server can conduct an ECC point verification step to verify that the received point from the key server comprising the second shared secret is a point on the ECC curve specified by the set of cryptographic parameters received in the first message. The server can conduct an ECC point addition operation using (i) the derived first shared secret by the server and (ii) the received second shared secret from the key server. The resulting value from the ECC point addition operation can comprise a third shared secret. The server can input the third shared secret into a key derivation function in order to derive a symmetric ciphering key. The server can encrypt a random number generated by the server and a certificate for the server using the derived symmetric ciphering key and the symmetric ciphering algorithm. The server can generate a digital signature for a fourth message with the certificate and the random number using the private key corresponding to the public key in the certificate. The data encrypted by the server, including the digital signature, can comprise a first ciphertext. The server can send the device the fourth message, where the fourth message includes the server ephemeral public key and the first ciphertext.

The device can receive the fourth message from the server and take steps to process the message. The device can conduct a third ECDH key exchange with the received server ephemeral public key. The device, using the set of cryptographic parameters, can perform an elliptic curve point addition operation on (i) the received server ephemeral public key from the fourth message and (ii) the recorded network static public key. The device can input (x) the point derived from the ECC point addition and (y) the device ephemeral private key into an ECDH key exchange algorithm in order to mutually derive the third shared secret with the server. Device can input the third shared secret into a key derivation function in order to derive the same symmetric ciphering key derived and used by the server. The device can decrypt the first ciphertext using the derived symmetric ciphering key. The device can read the plaintext from the first ciphertext. The device can take additional steps to communicate with the server, such as (i) verifying a signature in a certificate within the first ciphertext, (ii) using the public key from the certificate to verify a server digital signature for the fourth message, (iii) recording and using a public key for the server from the certificate in the first ciphertext, and other possibilities exist as well. The device can then use the derived symmetric ciphering key to encrypt a second ciphertext for the server and send the second ciphertext to the server in a fifth message. In exemplary embodiments, the derived symmetric ciphering key can comprise a first portion for encrypting and decrypting data sent from the server to the device and a second, different portion for encrypting and decrypting data sent from the device and to the server. The server can receive the fifth message and decrypt the second ciphertext using the same symmetric ciphering key derived by the server.

The systems and methods described above can also be used with particular implementations for a computing device and a server. A 5thgeneration or 6thgeneration wireless WAN network such as from 3GPP could utilize the steps above in order to conduct an ECDHE key exchange with a server authentication and a key server. For this embodiment, the computing device could comprise a wireless device or wireless terminal, including a mobile phone or smart phone. The server could comprise a “g Node B” for “next generation node b”, which provides equivalent functionality of a base transceiver station and manages the radio-frequency communications with the wireless device. The key server could comprise a secured server operating within the authentication function of a wireless network or associated with the authentication function of a wireless network for a mobile network operator. For the embodiment in this paragraph, the cryptographic parameters could comprise the values for curve 25519, although other ECC curves could be utilized as well.

The systems and methods described above can also be used with a device provisioning protocol. The computing device as described above can comprise an initiator according to the Device Provisioning Protocol specification version 1.0 from the WiFi Alliance®. The server can comprise a responder according to the same specification. Subsequent versions of the specification can utilize the methods and systems described herein as well. The device can receive and record the network static public key in the form of a responder bootstrap public key. A key server could record the network static private key in the form of a responder bootstrap private key. The responder/server can receive the first message with (a) the device ephemeral public key from the initiator/device along with (b) a secure hash value of the responder bootstrap public key, and (c) an initial ciphertext. The responder/server can use the secure hash value of the responder bootstrap public key to select the key server for the device. The responder/server can forward the device ephemeral public key to the selected key server. The key server can conduct the second ECDH key exchange with the device ephemeral public key and the responder bootstrap private key and send the second shared secret to the responder/server. The server can use the second shared secret to decrypt the initial ciphertext received with the first message.

These as well as other aspects and advantages will become apparent to those of ordinary skill in the art by reading the following detailed description, with reference where appropriate to the accompanying drawings.

DETAILED DESCRIPTION

FIG.1ais a graphical illustration of an exemplary system, where device communicates data with a network in order to conduct a key exchange, in accordance with exemplary embodiments. The system100can include a device103and a network105, where the nodes can communicate data106over an Internet Protocol (IP) network107. Network105can comprise a plurality of servers supporting communication such as data106with a plurality of devices103. In exemplary embodiments, network105can include a server101and a key server102. The exemplary servers shown for network105in system100can be either different physical computers such as rack-mounted servers, or different logical or virtual servers or instances operating in a “cloud” configuration. Or, server101and key server102could represent different logical “server-side” processes within a network105, including different programs running on a server that listen and communicate using different IP port numbers within one physical server. In exemplary embodiments, server101and key server102can operate using the physical electrical components depicted and described for a server101inFIG.1bbelow. Other possibilities exist as well for the physical embodiment of server101and key server102without departing from the scope of the present disclosure. In exemplary embodiments, server101can be described as a “first server” and key server102can be described as a “second server”. Further, the combination of a first server101and a second server102can comprise a network105. The combination of a first server101and a second server102can also comprise a “set of servers”.

Although server101and key server102are depicted inFIG.1aas belonging to the same network105, server101and key server102could be associated with different networks and communicate in a secure manner. Secure sessions between server101and key server102could be established over IP network107using methods including a physical wired connection via a local area network (LAN), transport layer security (TLS), a virtual private network (VPN), and IP Security (IPSEC), and other possibilities exist as well. As depicted inFIG.1a, server101and key server102could communicate over a private network107a.

Device103can be a computing device for sending and receiving data. Device103can take several different embodiments, such as a general purpose personal computer, a mobile phone based on the Android® from Google® or the IOS operating system from Apple®, a tablet, a networked device with a sensor or actuator for the “Internet of Things”, a module for “machine to machine” communications, a device that connects to a wireless or wired Local Area Network (LAN), an initiator according to the Device Provisioning Protocol specification (DPP) from the WiFi alliance, a router, and/or a server, and other possibilities exist as well without departing from the scope of the present disclosure. Exemplary electrical components within a device103can be similar to the electrical components for a server101depicted and described inFIG.1bbelow, where device103can use electrical components with smaller capacities and lower overall power consumption, compared to the capacity and power consumption for the same electrical components in a server101.

Device103can include a device identity103i, which could comprise a string or number to uniquely identify device103with network105and/or server101and server102. Device identity103icould comprise a medium access control (MAC) address for a physical interface such as Ethernet or WiFi, a Subscription Permanent Identifier (SUPI) with 5G networks, an international mobile subscriber identity (IMSI) or international mobile equipment identity (IMEI) with 2G/3G/4G networks, and other possibilities exist as well without departing from the scope of the present disclosure. In exemplary embodiments, device identity103ican be written to hardware in device103and operate as a unique, long-term identity for device103.

Device103can record at least one elliptic curve cryptography (ECC) static public key for network105comprising network static public key PK.network102a. Network static public key102acould be recorded in nonvolatile or volatile memory within device103. For embodiments where key102ais recorded in nonvolatile memory, key102acould be recorded by a device manufacturer or device distributor. For embodiments where key102ais recorded in volatile memory, device103could obtain key102afrom a different server than server101for network105before sending data106, such as device103obtaining key102avia a secure session from a different server before sending data106. A device103can record a plurality of different network static public keys102ain a network public key table103t. Different keys102ain a table103tcould be associated with different networks105or different servers101that device103communicates with over time. Exemplary data for a network public key table103tfor device103is depicted and described in connection withFIG.1cbelow. The different keys102acan be associated with network names and/or Uniform Resource Locators (URLs) or domain names, such that device103can select the network static public key102abased on a URL or domain name for a network105or a server101where device103will send data106.

Network static public key PK.network102acan be obtained by device103before conducting an elliptic curve Diffie-Hellman (ECDH) key exchange or an ephemeral elliptic curve Diffie-Hellman (ECHDE) key exchange. Network static public key102acould be obtained by device103in several different ways. Network static public key102acould be written into memory by a manufacturer, distributor, or owner of device103before device103connects with server101or a network105. Network static public key102acould be received by device103over an IP network107via a secured session, such as a TLS, DTLS, IPSec, or VPN connection before sending data106to server101. In exemplary embodiments, network static public key102ais recorded in device103in a secured and authenticated manner, such that device103can trust network static public key102a.

As one exemplary embodiment, network static public key102acould be a public key within a certificate, where the public key102ais signed by a certificate authority. Although not depicted inFIG.1a, device103could also record a certificate authority root certificate, and device103could (a) verify the signature of a certificate authority in a certificate for the public key102ausing (b) the recoded root certificate for the certificate authority (and any intermediary parent certificates). Network static public key102acould be processed or formatted according to a set of parameters104, and network static public key102acould also be compatible with parameters104. Although public key102ais described as “static”, the key could change over time such as with the expiration of a validity date when recorded in a certificate. Public key102acould remain static over the period of time for device103to conduct at least one ECDHE key exchange, where the ECDHE key exchange uses ephemeral or derived ECC PKI keys. Public key102acould comprise a long-term public key for use by device103when communicating with network105. Although the use of a certificate for public key102ais described in this paragraph for public key102a, the use of a certificate is not required. In an embodiment depicted inFIG.3cbelow, (i) public key102acould comprise a responder bootstrap public key and (ii) device103could comprise an initiator according to the DPP standard, which is also depicted and described in connection withFIG.3cbelow.

Device103can include an ECC key pair generation algorithm103xand server101can include a compatible ECC key pair generation algorithm101x. A key pair generation algorithm103xor101xcan use (i) a random number generator in order to derive the ephemeral PKI private key and (ii) a selected set of cryptographic parameters104in order to calculate the ephemeral PKI public key. In exemplary embodiments, a random number for the ephemeral PKI private key multiplies the base point G from the parameters104in order to obtain the corresponding ephemeral PKI public key. Other possibilities exist as well for the algorithms103xand101xto derive an ephemeral ECC PKI key pair without departing from the scope of the present disclosure. A key pair generation algorithm103xfor device103can output an ephemeral ECC PKI pair comprising device ephemeral public key Ed103aand device ephemeral private key ed103b. A key pair generation algorithm101xfor server101can output an ephemeral ECC PKI pair comprising server ephemeral public key E1101aand server ephemeral private key e1101b. As contemplated in the present disclosure, the use of a capital letter as the first character for a PKI key can represent a public key, the use of a lower case letter as the first character for a PKI key can represent a private key. As contemplated in the present disclosure, the second letter for a PKI key can represent the entity the key is associated with or belongs to (e.g. “d” for device103and “1” for server101).

Device103can also record a device static PKI key pair103pin nonvolatile memory or within a secure processing environment within device103. The key pair103pcan be either (i) generated by device103during device manufacturing or device distribution, or (ii) generated externally from device103and written to device103in a secure manner during device manufacturing or device distribution. The PKI key pair103pcan comprise a device static private key d1103dand a device static public key D1103c. The keys d1103dand D1103ccould be formatted and compatible with the set of cryptographic parameters104. In exemplary embodiments, public key D1103ccan be recorded in an X.509 certificate from a certificate authority.

As depicted inFIG.1a, server101can include a server identity101i, a key pair generation algorithm101x, a set of cryptographic parameters104, a server database101d, and a server certificate101c. Server identity101ican comprise a name or number to uniquely identify server101in network105and/or IP network107. In exemplary embodiments, server identity101ican comprise a domain name service (DNS) name, which could comprise a string of characters and/or numbers. Server identity101icould be associated with an IP address, such that the exemplary data106from device103could be routed to server101via the IP network107. Server identity101icould also comprise a MAC address, and a server identity101icould comprise multiple different values such as all of a MAC address, a DNS name, and virtual instance identity if server101operates as a virtual server. In summary, server identity101ican allow (a) a plurality of different devices103to (b) select and route data106to server101from a potential plurality of different servers and nodes. Server identity101icould also comprise a server name indication (SNI) value. Other possibilities exist as well for the format, structure, or value for a server identity101iwithout departing from the scope of the present disclosure.

A key pair generation algorithm101xfor server101was described above in connection with key pair generation algorithm103xfor device103. Key pair generation algorithm101xcan derive ephemeral ECC PKI keys for server101to use with ECDHE key exchanges for a plurality of different devices103. Note that although a single ECC PKI key pair of public key E1101aand private key e1101bis depicted for system100, server101could derive and operate with a plurality of different keys E1101aand e1101bwith different devices103. The plurality of different keys E1101aand e1101bfor communicating with different devices103could be recorded in a server database101das depicted and described in connection withFIG.2dbelow. The set of cryptographic parameters104for server101can be equivalent to or a superset of the cryptographic parameters104used by device103. The description above for a set of parameters104used by a device103is also applicable to a set of parameters104used by a server101.

Server database101dfor server101can comprise a database or memory recording data for server101to communicate with both a plurality of devices103and also at least one key server102. An exemplary server database101dis depicted and described in connection withFIG.2dbelow. Server database101dcan record values for PKI keys, derived shared secrets, derived symmetric ciphering keys, random numbers used in secure sessions, and related values in order to support the communications with both device103and key server102. Server certificate101ccan comprise a certificate formatted according to the X.509 family of standards and include a static server101public key PK.S1101p. Server certificate101ccan include a signature from a certificate authority for server public key PK.S1101p. Although not depicted inFIG.1a, server101can also record and operate with a private key corresponding to public key PK.S1101p.

As depicted inFIG.1a, key server102can include a key server identity102i, a set of cryptographic parameters104, a network static private key SK.network102b, and a key server database102d. Key Server identity102ican comprise a name or number to uniquely identify key server102in network105and/or IP network107. Key Server identity102ican be similar to server identity101i, except using a different value, name, or number in order to uniquely identify key server102within network105. The set of cryptographic parameters104for server102can be equivalent to or a superset of the cryptographic parameters104used by device103and parameters104was also described above for device103.

In exemplary embodiments, the parameters104used by both key server102and server101can be fully compatible, such as using the same ECC named curve, key lengths, encoding rules, etc. Server database102dfor key server102can comprise a database or memory recording data for key server102to (i) communicate with a plurality of servers101and (ii) support server101communicating with a plurality of devices103. Key server database102dcan be similar to server database101ddepicted inFIG.2d, except that key server database102dcan record values and data calculated by key server102. Key server database102dcan record values for PKI keys, derived shared secrets, and related values in order to support the communications between (i) network105and/or server101and (ii) device103. As depicted inFIG.1a, key server database102dcan record sets of data for different devices103, where each set can comprise a row in a table with a device identity103i, the network static public key value PK.network102a, and the network static private key SK.network102b. Although not depicted inFIG.1a, a key server database102dcould also record or store a secure hash value for the network public key102a, where the algorithm for the secure hash value could be specified in a member of the set of cryptographic parameters104. For some exemplary embodiments, (i) a device identity103icould be omitted from a key server database102dor (ii) the device identity103icould comprise a secure hash value over either the network public key102aor the device static public key103c.

As depicted for a key server database102dinFIG.1a, some devices103could share the same keys102aand102b, which could comprise shared keys102zfor the devices103as depicted and described in connection withFIG.1cbelow. Other devices103could record unique keys102v, where devices103record a value for the network static public key PK.network102athat is uniquely recorded in each device. A key server database102dcould record and track the associated network private and public keys for each device. In other exemplary embodiments, a key server102could omit recording device identities103iin a database102d, and key server102could associate and use a network static private key SK.network102bwith a particular server101(e.g. all data from a server101could use or be associated with the private key SK.network102b).

Other possibilities exist as well for the mapping of network static private keys to either servers101or devices103without departing from the scope of the present disclosure. Also, although a single value for SK.network102bis depicted as associated with a device103, a key server102could also use multiple different values of SK.network102b, such as (i) different values for SK.network102bfor different parameters104(e.g. different named curves), or (ii) separate values for SK.network102bfor digital signatures and ECDH key exchanges. In other words, a device103could also record the corresponding different multiple values for PK.network102a, and select and use the public keys depending on requirements such as parameters104used or if the network public key will be used for verifying digital signatures or conducting ECDH key exchanges.

Key server102can record at least one network static private key SK.network102b, which can be the private key corresponding to the network static public key PK.network102arecorded by device103and described above for device103. In exemplary embodiments and as depicted inFIG.1aand alsoFIG.2abelow, key server102may not communicate with device103directly, but rather communicates with server101through a private network107a. Although not depicted inFIG.1a, a network105could operate a firewall in order to prevent packets or data from the public Internet (other than server101) from reaching key server102. In this manner by isolating key server102from IP network107, security for the key server102and the network static private key SK.network102bcan be enhanced, since only authenticated and authorized nodes within network105and connected to private network107acould communicate with server102.

IP network107could be either a Local Area Network (LAN) or a Wide Area Network (WAN), or potentially a combination of both. IP network107could include data links supporting either IEEE 802.11 (WiFi) standards. Device103also utilize a variety of WAN wireless technologies to communicate data106with server101, including Low Power Wide Area (LPWA) technology, 3rd Generation Partnership Project (3GPP) technology such as, but not limited to, 3G, 4G Long-Term Evolution (LTE), or 4G LTE Advanced, NarrowBand—Internet of Things (NB-IoT), LTE Cat M, proposed 5G networks, and other examples exist as well. Server101can connect to the IP network107via a wired connection such as, but not limited to, an Ethernet, a fiber optic, or a Universal Serial Bus (USB) connection (not shown). IP network107could also be a public or private network supporting Internet Engineering Task Force (IETF) standards such as, but not limited to, such as, RFC 786 (User Datagram Protocol), RFC 793 (Transmission Control Protocol), and related protocols including IPv6 or IPv4. A public IP network107could utilize globally routable IP addresses. Private IP network107acould utilize private IP addresses which could also be referred to as an Intranet. Other possibilities for IP Network107and Private Network107aexist as well without departing from the scope of the disclosure.

FIG.1bis a graphical illustration of hardware, firmware, and software components for a server, in accordance with exemplary embodiments.FIG.1bis illustrated to include several components that can be common within a server101. Server101may consist of multiple electrical components in order to communicate with a plurality of devices101and a key server102. In exemplary embodiments and as depicted inFIG.1b, server101can include a server identity101i, a processor101e(depicted as “CPU101e”), random access memory (RAM)101f, an operating system (OS)101g, storage memory101h(depicted as “nonvolatile memory101h”), a Wide Area Network (WAN) interface101j, a LAN interface101k, a system bus101n, and a user interface (UI)101m.

Server identity101icould comprise a preferably unique alpha-numeric or hexadecimal identifier for server101, such as an Ethernet MAC address, a domain name service (DNS) name, a Uniform Resource Locator (URL), an owner interface identifier in an IPv6 network, a serial number, an IP address, or other sequence of digits to uniquely identify each of the many different possible nodes for a server101connected to an IP network105. Server identity101icould comprise a server name indicator (SNI). Server identity101ican preferably be recorded in a non-volatile memory and recorded by a network105upon configuration of a server101. Server identity101imay also be a number or string to identify an instance of server101running in a cloud or virtual networking environment. In exemplary embodiments, server101can operate with multiple different server identities101i, such as a first server identity101icomprising a DNS name and a second server identity101icomprising an IP address and a port number. A different server101could be associated with a different IP address and port number for a network105.

The CPU101ecan comprise a general purpose processor appropriate for higher processing power requirements for a server101, and may operate with multiple different processor cores. CPU101ecan comprise a processor for server101such as an ARM® based process or an Intel® based processor such as belonging to the XEON® family of processors, and other possibilities exist as well. CPU101ecan utilize bus101nto fetch instructions from RAM101fand operate on the instruction. CPU101ecan include components such as registers, accumulators, and logic elements to add, subtract, multiply, and divide numerical values and store or record the results in RAM101for storage memory101h, and also write the values to an external interface such as WAN interface101jand/or LAN interface101k. In exemplary embodiments, CPU101ecan perform the mathematical calculations for a key pair generation step101xand also an ECDH key exchange algorithm220depicted inFIG.2a,FIG.2b, etc., below.

CPU101ecan also contain a secure processing environment (SPE)101sin order to conduct elliptic curve cryptography (ECC) operations and algorithms, such as an ECC point addition step214depicted inFIG.2cbelow, as well as deriving ephemeral ECC PKI keys such as with key generation step101xdepicted and described in connection withFIG.1aabove. SPE101scan comprise a dedicated area of silicon or transistors within CPU101ein order to isolate the ECC operations from other programs or software operated by CPU101e, including many processes or programs running operating system101g. SPE101scould contain RAM memory equivalent to RAM101fand nonvolatile memory equivalent to storage memory101h, as well as a separately functioning processor on a smaller scale than CPU101e, such as possibly a dedicated processor core within CPU101e. SPE101scan comprise a “secure enclave” or a “secure environment”, based on the manufacturer of CPU101e. In some exemplary embodiments, an SPE101scan be omitted and the CPU101ecan conduct ECC operations or calculations without an SPE101s.

RAM101fmay comprise a random access memory for server101. RAM101fcan be a volatile memory providing rapid read/write memory access to CPU101e. RAM101fcould be located on a separate integrated circuit in server101or located within CPU101e. The RAM101fcan include data recorded in server101for the operation when communicating with a plurality of devices103or a key server102. The system bus101nmay be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures including a data bus. System bus101nconnects components within server101as illustrated inFIG.1b, such as transferring electrical signals between the components illustrated. Server101can include multiple different versions of bus101nto connect different components, including a first system bus101nbetween CPU101eand RAM101f(which could be a memory bus), and a second system bus101nbetween CPU101eand WAN interface101jor LAN interface101k, which could be an I2C bus, an SPI bus, a PCI bus, or similar data busses.

In exemplar embodiments, RAM101foperating with server101can record values and algorithmic steps or computer instructions for conducting an ECDH key exchange, including a key pair generation step101x, a secret X1211a(depicted inFIG.2bbelow) and also a secret X2212a(depicted inFIG.2bbelow). The depicted values and algorithms can be recorded in RAM101fso that CPU101ecan conduct ECC operations and calculations quickly using the values. The depicted values could also be recorded in other locations for longer-term or nonvolatile storage, such as within a server database101d. Additional or other values besides the ones depicted inFIG.1bcan also be recorded in RAM101fin order to support server101conducting the communications, steps, and message flows depicted inFIG.2abelow and other Figures herein.

The operating system (OS)101gcan include Internet protocol stacks such as a User Datagram Protocol (UDP) stack, Transmission Control Protocol (TCP) stack, a domain name system (DNS) stack, a TLS stack, a DPP stack, etc. The operating system101gmay include timers and schedulers for managing the access of software to hardware resources within server101, where the hardware resources managed by OS101gcan include CPU101e, RAM101f, nonvolatile memory101h, and system bus101n, and well as connections to the IP network107via a WAN interface101j. The operating system shown of101gcan be appropriate for a higher power computing device with more memory and CPU resources (compared to a device103). Example operating systems101gfor a server101includes Linux or Windows® Server, and other possibilities exist as well. Although depicted as a separate element within server101inFIG.1b, OS101gmay reside in RAM101fand/or nonvolatile memory101hduring operation of server101.

As depicted inFIG.1b, OS101ginFIG.1bcan contain algorithms, programs, or computer executable instructions (by processor101eor SPE101s) for an ECDH key exchange algorithm220(depicted and described inFIG.2bandFIG.2ebelow), a key derivation function (KDF)216(depicted and described inFIG.2bandFIG.2ebelow), and also an ECC point addition operation214(depicted and described inFIG.2bandFIG.2ebelow). The algorithms could be included either (i) within the kernel of OS101g, or (ii) as a separate program or process loaded by OS101gand operated by OS101g. OS101gcan also read and write data to a secure processing environment SPE101s, if CPU101econtains SPE101s.

Nonvolatile memory101hor “storage memory”101h(which can also be referred to herein as “memory101h”) within server101can comprise a non-volatile memory for long-term storage of data, including times when server101may be powered off. Memory101hmay be a NAND flash memory or a NOR flash memory and record firmware for server101, such as a bootloader program and OS101g. Memory101hcan record long-term and non-volatile storage of data or files for server101. In an exemplary embodiment, OS101gis recorded in memory101hwhen server101is powered off, and portions of memory101hare moved by CPU101einto RAM101fwhen server101powers on. Memory101h(i) can be integrated with CPU101einto a single integrated circuit (potentially as a “system on a chip”), or (ii) operate as a separate integrated circuit or a removable card or “disk”, such as a solid state drive (SSD). Storage memory101hcan also comprise a plurality of spinning hard disk drives in a redundant array of independent disks (RAID) configuration. Memory101hmay also be referred to as “server storage” and can include exemplary file systems of FAT16, FAT 32, NTFS, ext3, ext4, UDF, or similar file systems. As contemplated herein, the terms “memory101h”, “storage memory101h”, and “nonvolatile memory101h” can be considered equivalent.

As depicted inFIG.1b, non-volatile memory101hcan record a server database101d, a device static public key D1103c, and cryptographic parameters104. Exemplary data within a server database101dis depicted and described in connection withFIG.2dbelow. Although depicted inFIG.1bas recorded within memory101h, a server database101dcould also operate as a separate server than server101in a network105, and server101could query the server database101dusing a private network107a. The device static public key D1101ccould be received by server101from a device manufacturer or a device owner, or directly from device103through IP network107. In addition, as depicted inFIG.1b, memory101hcan record the parameters104which were depicted and described in connection withFIG.1aabove and alsoFIG.2dbelow.

Server101can include a WAN interface101jto communicate with IP network107and a plurality of devices103, as depicted inFIG.1aabove (whereFIG.1adepicts a single device103). WAN interface101jcan comprise either a wired connection such as Ethernet or a wireless connection. For wireless configurations of server101, then WAN interface101jcan comprise a radio, which could connect with an antenna in order to transmit and receive radio frequency signals. For a wireless configuration of server101, WAN interface101jwithin server101can provide connectivity to an IP network107through 3GPP standards such as 3G, 4G, 4G LTE, and 5G networks, or subsequent and similar standards. In some exemplary embodiments, server101can comprise a “g node b” or gNb in a 5G network (or equivalent functionality in 6G or subsequent networks), and WAN interface101jcan comprise a 5G radio access network (RAN) interface. WAN interface101jcan also comprise a wired connection such as digital subscriber line (DSL), coaxial cable connection, or fiber optic connection, and other possibilities exist as well without departing from the scope of the present disclosure.

Server101may also operate a LAN interface101k, where LAN interface101kcan be used to connect and communicate with other servers in a network107, such as key server102through private network107a. LAN interface101kcan comprise a physical interface connected to system bus101nfor server101. In exemplary embodiments, LAN interface101kcan comprise an Ethernet or fiber optic wired connection. In other words, (i) LAN interface101kcan connect server101to private network107a(which could comprise an IP network with private IP addresses that are not globally routable), and (ii) WAN interface101jcan comprise an interface for communicating with a plurality of devices103through insecure networks such as the globally routable public Internet. The use of a separate WAN interface101jand LAN interface101kcan increase the security of operation for server101. However, the use of separate physical interfaces for LAN interface101kand WAN interface101jcan be omitted, and a single physical interface such as Ethernet or fiber-optic could be used by server101to communicate with both devices103and key server102.

Server101may also optionally include user interface101mwhich may include one or more sub-servers for receiving inputs and/or one or more sub-servers for conveying outputs. User interfaces are known in the art and may be simple for many servers101such as a few LED lights or and LCD display, and thus user interfaces are not described in detail here. User interface101mcould comprise a touch screen or screen display with keyboard and mouse, if server101has sophisticated interaction with a user, such as a network administrator. Server101can optionally omit a user interface101m, if no user input or display is required for establishing communications within a network105and/or IP network107. Although not depicted inFIG.1b, server101can include other components to support operation, such as a clock, power source or connection, antennas, etc. Other possibilities exist as well for hardware and electrical components operating in a server101without departing from the scope of the present disclosure. Using the electrical components depicted inFIG.1b, a server101could send and receive the data106inFIG.1ain an encrypted and secure manner after conducting the authenticated ECDHE key exchange as contemplated herein, in order to derive a symmetric ciphering key to encrypt and decrypt messages within data106with a plurality of devices103.

Although not depicted inFIG.1b, devices103such as the device103depicted inFIG.1aabove can include (a) equivalent internal electrical components depicted for a server101in order to (b) operate as devices103. A device103inFIG.1acould include a processor similar to CPU101e, with primary differences for the processor in a device being reduced speed, a smaller memory cache, a smaller number and size of registers, with an exemplary use of 32 bits for datapath widths, integer sizes, and memory address widths, etc., for a device103. In contrast, an exemplary 64 bit datapaths could be used for CPU101ein server101(although device103could also use 64 bit wide datapath widths if device103comprises a mobile phone such as a smart phone). For embodiments where device103comprises a transducer device for sending and receiving transducer data with a network105, then a CPU in device103could comprise an exemplary 32 bit processor, although other possibilities exist as well.

Similarly, RAM in a device103could be a RAM similar to RAM101fin server101, except the RAM in a device103could have fewer memory cells such as supporting exemplary values less than or equal to an exemplary 4 gigabytes, while RAM103fin server101could support more memory cells such as greater than or equal to an exemplary 8 gigabtyes. In exemplary embodiments, the electrical and physical components of a key server can be equivalent to the electrical components for a server101inFIG.1b, with different data recorded in RAM101ffor a key server102, as well as different data recorded in memory101hfor a key server102. For example, a key server102could record the network static private key SK.network102bin memory101h, which could include secure disk storage using disk or file encryption.

FIG.1cis an illustration of exemplary network static public keys recorded by a plurality of devices, in accordance with exemplary embodiments.FIG.1cdepicts PKI keys recorded for an exemplary three different devices103, although a system100and other systems herein could operate with potentially millions or more devices103. The data depicted for each device inFIG.1ccan comprise exemplary data for a network public key table103tfor a device103, which is also depicted and described in connection withFIG.1aabove. The exemplary values recorded for network static public keys depicts different embodiments where both (i) a device103can record a network static public key PK.network102athat is shared with other devices103, and (ii) the network static public key PK.network102arecorded by device103could be unique for device103(e.g. not shared with other devices103in a system100above or a system200below, as well as other systems herein). A network public key table103tfor device103can record values of a key identity, a network name for network105, an identity for server101comprising ID.server101i, and also a value for the network static public key PK.network102a. As depicted inFIG.1c, a device103can record multiple different values for use with multiple different networks105and/or servers101.

The first two entries for network static public keys PK.network102afor a first device103(1) and a second device103(2) inFIG.1cdepicts the same alphanumeric values for basE91 binary to text encoding for an exemplary network static public keys PK.network102ain a first device103(1) and a second device103(2), where the key value is depicted for a network105of “Network A”. Likewise, the second two entries for network static public keys PK.network102afor a first device103(1) and a second device103(2) inFIG.1cdepicts the same alphanumeric values for basE91 binary to text encoding for an exemplary network static public key PK.network102ain a first device103(1) and a second device103(2). Note that although a single value is depicted for PKI keys in a network public key table103t, the values or numbers for keys recorded could comprise a point on an ECC curve with both an X coordinate and a Y coordinate. For illustration purposes inFIG.1c, only the X coordinate is displayed and the Y coordinate could be calculated from the X coordinate using the equation for an ECC curve in a set of cryptographic parameters104afor the PKI keys.

The depiction of these keys PK.network102aillustrates the use of shared keys102zfor a plurality of different devices103. Although only two devices are depicted with shared keys102z, many more devices could also record the same shared keys for PK.network102a. Each of the shared keys102zis associated with a different network105, identified with an exemplary different network name. In this manner, a plurality of different devices103can record and use the same value for a network static public key PK.network102a. As described above, the value in a table103tincluding network static public key PK.network102acould be written in device before the device sends the first message203inFIG.2abelow. The data could be recorded by a device manufacturer, a device distributor, or a device owner, and other possibilities exist as well for the source of PK.network102awithout departing from the scope of the present disclosure.

The same values for shared keys102zacross different devices103could be recorded in device103during manufacturing or before distribution to end users of device103. In this manner, devices103could be received by end users in a “partially configured” yet secure state, such that a device103could use the recorded keys PK.network102awith a server101and/or network105, where a server101does not operate or record the corresponding network static private key SK.network102b. As depicted and described in connection withFIGS.2a,2b, etc. below, a key server102could record and operate with the corresponding network static private key SK.network102band thus the key SK.network102bcan remain secured and not distributed out or sent to a server101. In this manner, encrypted communications for data106inFIG.1acan be transferred between device103and server101without server101recording the key SK.network102b. This increases the security of a system100and other systems herein, because server101may be exposed to an IP network107while key server102recording the SK.network102bcan be connected to a private network107a.

By using a set of shared keys102zacross a plurality of device103, a key server102or a network105can control access of the devices103as a group. For example, a network105could deny access to the private key corresponding to the public key for the first depicted value of PK.network102ain a first device103(1). That action by network105would also deny a second device103(2) access to the private key corresponding to the public key for the first depicted value of PK.network102ain the second device103(2). In this manner, network105could control access to a plurality of different devices103by controlling access to a single value of SK.network102b, where (i) the plurality of different devices103record the corresponding PK.network102aas shared keys102z. Other benefits for using shared keys102zcan be available as well, such as simplifying manufacturing or distribution, since the same key value for PK.network102acould be recorded with multiple different devices103. In other words, a device manufacturer or device distributor would not need to keep track of which value for PK.network102abelongs with which device103for embodiments where shared keys102zare utilized. However, the use of shared keys102zfor multiple different devices103is not required for some exemplary embodiments.

In exemplary embodiments, network static public keys PK.network102acan also comprise a unique key for each device103in a system100and other systems herein. Thus, some exemplary embodiments also support the use of a network static public key PK.network102athat is not shared across multiple different devices103. For these exemplary embodiments, and as depicted inFIG.1c, a device103can record a unique key102v(depicted as “Per Device or Unique Network Static Public Keys102v” inFIG.1c). For example, the depicted value for the third key for device103(1), (2), and (3) inFIG.1cis shown as unique for each device. A key server102could also record the corresponding network static private key SK.network102bthat is unique for each device in a key server database102das depicted for unique keys102vinFIG.1a. In this manner, a network105can control access to server101and/or network105on a per-device basis using the unique key102v. For example, key server102could deny access to device103(3) (while continuing to allow service for device103(1) and103(2)), by denying access or cryptographic operations with the secret key SK.network102bin a key server102corresponding to the public key PK.network102arecorded by device103(3). Other benefits for recording network static public keys PK.network102aas unique keys102vfor devices103exist as well without departing from the scope of the present disclosure.

Although not depicted inFIG.1c, each row or network static public key PK.network102acould also be stored with a set of cryptographic parameters104a, such as specifying an ECC named curve associated with the public key102a. A network105or a server ID101icould be associated with multiple different network static public keys PK.network102a, where the different keys102afor the same network105or server ID101iare associated with different parameters104a. Although depicted as alphanumeric values for the network static public key PK.network102a, a network public key table103tcould store the public key102aas separate certificates for the public keys. In addition, a network public key table103tcould store a secure hash value for the network static public key PK.network102a, where the secure hash algorithm104dfor the secure hash value could be specified by parameters104, as depicted and described in connection withFIG.2dbelow. In addition, a table103tcould include a key server identity102iassociated with the network static public key PK.network102a.

FIG.2ais a simplified message flow diagram illustrating an exemplary system with exemplary data sent and received by a device, a server, and a key server, in accordance with exemplary embodiments. System200can include a device103, server101, and a key server102. Device103was depicted and described in connection withFIG.1a, andFIG.1cabove. Server101and key server102were depicted and described in connection withFIG.1aabove, and server101was depicted and described in connection withFIG.1babove. Server101can record and operate a server database101d, and key server102can record and operate a database102d. Individual steps and components used in system200inFIG.2aare also additionally depicted and described in subsequentFIGS.2b,2c, and2d. Before starting the steps and message flows depicted inFIG.2a, device103can securely receive and record a network public key PK.network102a, which was also depicted and described in connection withFIG.1aandFIG.1c. The corresponding private key for PK network102acan be securely recorded in key server102within network105as SK.network102b.

For system200, server101and key server102may establish a secure session221, which could comprise establishing a secure communications link between the two servers using protocols such as TLS, IPSec, a virtual private network (VPN), a secure shell (SSH), or similar networking, transport, or application layer technologies in order to establish secure communications between key server102and server101. Secure session221can utilize certificates for the two servers in order to provide mutual authentication and mutual key derivation for a symmetric encryption key in secure session221. Secure session221can also be conducted over private network107a, although the secure session221could also be established or conducted through an IP network107such as the globally routable Public Internet. Other possibilities exist as well for establishing a secure session221between server101and key server102without departing from the scope of the present disclosure. Although not depicted inFIG.2a, firewalls between server101and key server102could also be utilized in order to establish or conduct secure session221. At step201b, server101can begin listening for incoming messages from a device103using a physical network interface such as WAN interface101jthat provides connectivity to the IP network107and server101can use a specific port number such as, but not limited to, TCP port443to listen for incoming data106from a device103.

At step201a, device103can be powered on and begin operating, in order to establish connectivity with an IP network107. At step202, device103can read an address for server101from memory or a network public key table103t, and the address can comprise a DNS name or an IP address for server101. The DNS name or IP address for server101could be recorded or received along with the key PK.network102a, or device103could conduct a DNS query to obtain the address. At step202, device103can also read the set of cryptographic parameters104and select a subset of the cryptographic parameters104ain order to establish communications with server101. An exemplary subset of cryptographic parameters104ain a step202can comprise a member of the set the cryptographic parameters104depicted and described in connection withFIG.2dbelow (e.g. one line of values in cryptographic parameters104inFIG.2dbelow). In step202, device103can select a subset of cryptographic parameters104athat is compatible with PK.network102a. The subset of cryptographic parameters104athat are compatible with PK.network102acould also be recorded in nonvolatile memory in device103along with network public key PK.network102aat the time PK.network102awas recorded or received by device103.

A step202can also comprise device103also using a random number generator in order to output a random number202afor use in subsequent communications with server101. Although the term “random number” is described herein, a random number could comprise a pseudo random number processed by device103using information entropy available to device103. The random number202aprocessed in a step202could contain the number of bits specified by a selected subset of cryptographic parameters104, such as a random length104g. Random number202agenerated or derived by a device103in a step202could also comprise a “number used once” (nonce).

Device103can then conduct a key pair generation step103xas depicted and described in connection withFIG.1aabove using the selected subset of cryptographic parameters104a. The parameters104could specify a named curve and parameters to derive a device ephemeral private key ed103band a device ephemeral public key Ed103a. The device ephemeral private key ed103bcan comprise a random number generated using a random number generator. The device ephemeral public key Ed103acould be derived using (i) ECC point multiplication from a base point G for a named curve within cryptographic parameters104aand (ii) the device ephemeral private key ed103b. Other possibilities exist as well for the steps a device103can use in a key pair generation step103xwithout departing from the scope of the present disclosure.

Device103can then use (i) the recorded address for server101(possibly from a table103t) and (ii) connectivity to IP network107from step202to send a message203to server101. Message203and other messages contemplated herein can be sent as either TCP or UDP messages, and other possibilities exist as well for the formatting and transfer of messages without departing from the scope of the present disclosure. In exemplary embodiments, device103both uses an IP address and port number as a source IP address and port to send message203to server101and then also the same IP address and port number to listen for responses or messages from server101. In this manner, device103can send a message203and receive a response message206cbelow through an IP network107, where intermediate nodes on the IP network107may conduct network address translation (NAT) routing.

Message203can include the random number random1202afrom a step202, the device ephemeral public key Ed103a, and the subset of cryptographic parameters104a. Message203may also optionally include a device identity of ID.device103i, but the device identity of ID.device103ican also be omitted from a message203in some exemplary embodiments. For embodiments where message203optionally excluded device identity ID.device103i, then an identity for device103ican optionally be transmitted in later messages. Omitting ID.device103ifrom message203can increase security for message203since an identity for device103would not be sent as plaintext in a message203. Although not depicted inFIG.2a, message203could also optionally include an identity for key server102comprising ID.key-server102i, such that server101can determine which key server102ishould be associated with message203. Note that an identity for key server102of ID.key-server102ican be omitted from a message203, and server101can select a key server102from other means in a step205bbelow.

As depicted inFIG.2a, message203could also optionally include a secure hash value250(also depicted inFIG.2dbelow) such as, but not limited to, SHA-256 of the network static public key PK.network102a. Device103can send the hash value250of key102ato server101in a message203, in order for server101to identify which of a plurality of possible key servers102could be used to process data within message203, which is further described for a step205bbelow. For embodiments where a secure hash value250of key102ais included in a message203, then the message203could optionally exclude the selected subset of cryptographic parameters104aassociated with keys PK.network102aand Ed103a. For other embodiments, a key identity for key102acould be selected by device103from a table103tand the key identity for key102acould be sent in a message203instead of a hash value205for key102a. A server101and key server102could store the key identity for key102aand select the key102ausing the key identity for key102a.

Server101receiving the message203with the hash value250could determine the set of parameters104ato use for key Ed103abased on the hash value250. For example, and as depicted inFIG.2dbelow, a server database101dcould maintain mapping of hash values250and parameters104a, and server101could conduct a query of database101dusing the received hash value250in order to select the parameters104afor further processing and cryptographic operations with key Ed103a. Or, in an exemplary embodiment cryptographic parameters104aas transmitted via an IP network107or private network107acould comprise the secure hash250of key102a, where the secure hash250of key102acan specify which subset of a set of cryptographic parameters104to utilize for ECC operations (in other words the subset of parameters104can comprise parameters104a). For embodiments where device103uses a unique key102v, then the secure hash value250can also comprise a device identity103i(since the secure hash value250would be unique for device103). Secure hash value250could also be omitted from message203in some exemplary embodiments.

Server101can receive message203and begin conducting steps in order to process the message. At step204, server101can read the subset of cryptographic parameters104ain the message203and being using the subset of cryptographic parameters. Or, for embodiments that include hash value250, then parameters104acould be omitted from message203and server101could select the parameters104afrom a server database101dusing the hash value205, such as with the exemplary server database depicted inFIG.2dbelow. At step204, server101can comprise a public key validation step on received device ephemeral public key Ed103ain order to ensure the key is valid and on the selected curve in parameters104a. Step204by server101can comprise conducting the steps for an ECC Full Public-Key Validation Routine in section 5.6.2.3.2 of FIPS publication SP 800-56A (revision 2) for the received device ephemeral public key Ed103a. Alternatively, step204can comprise server101performing the steps ECC Partial Public-Key Validation Routine in section 5.6.2.3.3 of the same FIPS publication. Other example steps within a public key validation step204can comprise (i) verifying the public key is not at the “point of infinity”, and (ii) verifying the coordinates of the point for the public key are in the range [0, p−1], where p is the prime defining the finite field. Other possibilities exist as well for evaluating and validating a received public key is cryptographically secure in a public key validation step204, without departing from the scope of the present disclosure. As contemplated in the present disclosure a device103, server101, and key server102can conduct a public key validation step204each time a public key or a point on an elliptic curve is received.

At step205aand after a key validation step204, server101can record the data received from the message203in a server database101d. Exemplary values and data for a server database101dare depicted and described in connection withFIG.2dbelow. At step205a, server101can record in server database101dthe values of random number202a, device ephemeral public key Ed103a, and the subset of cryptographic parameters104d. For embodiments where device identity ID.device103iis also received in message203, then server101can also record device identity ID.device103iin server database101d. A step205acan also include (i) storing both Ed101aand random1202ain database101d, and (ii) confirming that Ed101aand random1202aare not reused. Security of a system200and system100and other systems herein can be increased through prohibiting the reuse of ephemeral PKI key pairs and also random numbers. If numbers or keys are reused, then server101could respond with a request for device103to generate a new ephemeral PKI key pair and/or random number202abefore proceeding to further steps. For embodiments requiring higher security, then hash values for received keys Ed101acould be stored in a database101d(instead of the value of key Ed101a), and a new Ed101areceived by server101could be determined as new or reused by calculating a hash value for the received key Ed101aand comparing with stored values for Ed101a.

At step205a, server103can also record the originating source IP address and port number203a(depicted inFIG.2dbelow) for message203, in order to subsequently transmit a message206cbelow back to the same IP address and port number. In this manner, message206cbelow can be routed by intermediate nodes on IP network107back to the source IP address and port number used by device103to transmit message203. In other words, (i) the destination IP address and port number of a subsequent message206cfrom server101to device103can comprise the source IP address and port number203a(depicted inFIG.2dbelow) received in message203, and (ii) the source IP address and port number203a(depicted inFIG.2dbelow) from message203can be recorded in a server database101d. In this manner, device103can be tracked or identified by server101during the brief period of time of the message flows inFIG.2ausing the source IP address and port number from message203for embodiments where device identity ID.device103iis not included in message203. A step205acan also comprise server101generating a second random number205rusing parameters104afor use in subsequent messages with device103. The first random number can comprise random number random1202aderived by device103.

At step205b, server101can select key server102for subsequent communications and processing of the received device ephemeral public key Ed103a. Note that a system100could comprise both a plurality of devices103and a plurality of key servers102. In exemplary embodiments server101should select in step205bthe proper key server102for conducting subsequent steps inFIG.2a. In other words, without data or values from a message203, server101may know which of a possible plurality of key server102may record the network static private key SK.network102bfor use with or associated with device ephemeral public key Ed103a. Server101could use one of several possible methods for selecting key server102in a step205b, including a combination of the following embodiments.

A first embodiment for selecting key server102in a step205bcould comprise server101selecting the same key server102for all keys Ed103afrom all devices103. For example for this first method, server101could listen or operate on (i) a specific IP address and port number or (ii) with a specific DNS name or server name indicator (SNI) in step201b, where the use of (i) or (ii) could be specified or associated with network static public key PK.network102a. As mentioned above for a step201a, device103can select the address of server101using the server address of server101recorded with PK.network102a(possibly from a table103tinFIG.1c). Server101could determine that all messages203received using (i) or (ii) are associated with a specific key server102. For this first embodiment of a step205b, a plurality of devices103could store shared keys102vfor PK.network102a, as depicted and described in connection withFIG.1c.

A second embodiment of a step205bfor selecting key server102of received device ephemeral public key Ed103acould comprise using an identity of key server102in a message203from device103. As described above for a message203, the message203can optionally include an identity for key server102comprising ID.key-server102i. For these embodiments, server101can select the key server102using the ID.key-server102iin message203. A third embodiment for a step205bof selecting key server102for received device ephemeral public key Ed103acould comprise using an identity of device103in a message203comprising ID.device103i. As described above for a message203, the message203can optionally include an identity for device103, and server101using database101dcould include a table to map ID.device103ito key server102. For this third embodiment of a step205b, server101could conduct a query of server database101dto select the key server102for device103using ID.device103i.

A fourth embodiment for a step205bto select a key server102for received device ephemeral public key Ed103acould comprise using the subset of cryptographic parameters104ain a message203from device103. Server101could record that a first subset of cryptographic parameters104aare associated with a first key server102, and a second subset of cryptographic parameters104aare associated with a second key server102, etc. A fifth embodiment for a step205bto select a key server102for received device ephemeral public key Ed103acould comprise message205including a secure hash value250(inFIG.2d) of network static public key PK.network102a, and server101with database103dcould include a table to map the secure hash value250of PK.network102ato key server102. Other possibilities exist as well for server101to conduct a step205bto select a key server102using data in a message203without departing from the scope of the present disclosure. For embodiments of step205b, the selection of key server102can comprise the selection of an identity for key server102of key server identity102i, and subsequent data such as message206acould be sent or routed through IP network107ausing the key server identity102i.

After selecting key server102in a step205b, server101can then send key server102a message206athrough the secure session221. Message206acan include an identity for server101comprising ID.server101i, the received device ephemeral public key Ed103a, and the subset of cryptographic parameters104a. For embodiments where device identity ID.device103iwas included in a message203, then ID.device103icould be included in a message206aas well. However, device identity ID.device103icould be omitted from a message203and for these embodiments then message206acan exclude device identity ID.device103ias well. Server identity ID.server103ican be useful for communications between key server102and server101for a system100and system200, since either (i) server101may communicate with a plurality of different key servers102, and/or (ii) key server102may communicate with a plurality of different servers101.

Server101can then conduct a key pair generation step101xas depicted and described in connection withFIG.1aabove using the selected subset of cryptographic parameters104a. The parameters104acould specify a named curve and parameters to derive a server ephemeral private key e1101band a server ephemeral public key E1101a. The server ephemeral private key e1101bcan comprise a random number generated using a random number generator. The server ephemeral public key E1101acould be derived using (i) ECC point multiplication from a base point G for a named curve within cryptographic parameters104aand (ii) the server ephemeral private key e1101b. Although message206ais depicted inFIG.2aas transmitted or sent by server101to key server102before server101derives ephemeral server PKI keys in a step101x, a message206acould be sent by server101after server101conducts the step101x. Key pair generation step101xcan also confirm that the server ephemeral PKI key pair for server101is not reused, such as storing hash values for public keys E1101ain a database101dand then comparing the hash value for a new key E1101afrom a step101xwith the stored hash values. If the derived new key E1101amatches a stored hash value101afrom a database101d, then the new key E1101acould be discarded and a different key E1101aderived.

Key server102can receive the message206avia the secure session221and conduct a series of steps to process the message and respond. A first step conducted by key server102can comprise a key validation step204, where the key validation step204conducted by key server102can be equivalent or compatible with the key validation step204conducted by a server101as described above. For a key validation step204, a node can reply with a failure or reject message if the key validation step204fails, such as if a received ECC public key fails to fall on the named elliptic curve as specified by a subset of cryptographic parameters104a.

At step205c, key server102can use data from message206ain order to select a network static private key SK.network102bfor subsequent steps such as a step211. For embodiments where message206aincludes either (i) an identity for device103such as ID.device103i, or (ii) identifying information for SK.network102bfor key server102to utilize (such as hash250of the public key PK.network102afor SK.network102b), then key server102could use the identifying information in message206ato select the network static private key SK.network102bfrom a key server database102d, where an exemplary key server database102dis depicted and described in connection with inFIG.1aabove. For some exemplary embodiments, the key server database102dcan record a network static private key SK.network102bfor each set of cryptographic parameters104a, and subsequently select the key102busing the parameters104areceived in a message206a. In other words, an identity for device103or hash250of PK.network102acould be omitted, and a key server102could use a step205cto select a network static private key SK.network102busing a set of cryptographic parameters104a.

Key server102can then conduct an ECDH key exchange step211using (i) the selected network static private key SK.network102b, (ii) the received device ephemeral public key Ed103a, and (iii) the set of cryptographic parameters104a. Exemplary details for an ECDH key exchange step211are depicted and described in connection withFIG.2bbelow. The output of an ECDH key exchange step211can comprise point X1211a.

Key server102can then send server101a message206b, where the message206bincludes point X1211a, as well as an identity for key server102comprising ID.key-server102iand cryptographic parameters104aassociated with point X1211a. Message206bcan be transmitted through secure session221. If device identity103ior other identifying information such as hash250was included in message206a, then message206bcould also include device identity103ior the other identifying information for a device103. Or, both message206aand message206bcan include a transaction identity or session identity, such that server101can associate the received value X1211awith a received device ephemeral public key Ed103a.

Server101can receive message206awith point X1211aand conduct a series of steps in order to derive a mutually shared and authenticated key exchange with device103. As contemplated herein, the authentication performed by server101can comprise a “one-way” authentication with device103. Authentication of server101or network105can be provided by the depicted key exchange with steps211and213, since network105from system100with both server101and key server102conducts an ECDH key exchange using at least, in part, the network static private key SK.network102b. The “one-way” authentication from the ECDH key exchange is also not completed until both sides have successfully used a symmetric ciphering key derived from the ECDH key exchange. In other words, a device that successfully mutually derives a symmetric ciphering key with a server101can authenticate that server101has secure access to the network static private key SK.network102b. One benefit of the system depicted inFIG.2ais that the network static private key SK.network102bdoes not need to be recorded by or operated with server101. Further authentication of both parties can be completed via other means including digital signatures in later steps, and the “one-way” authentication in this paragraph refers to the authentication that results from using the ECDH key exchange using at least network static private key SK.network102b.

Note that the authenticated ECDH key exchange depicted inFIG.2a, with additional details in subsequent Figures, can solve problems in the art discussed in the Description of Related Art. Specifically, through the use of a PK.network102arecorded by a device and SK.network102brecorded by a network105, combined with the use of ephemeral PKI keys for both device103and server101, the depicted and described ECDH key exchange herein can simultaneously achieve both (i) authentication of a network105with device103and (ii) forward secrecy. As discussed in the Description of Related Art, a device103may not have full access to the Internet (such as other servers or networks besides those for a network105), or other resource limitations such as not storing (x) intermediate certificate authority certificates for servers or (y) compatible parameters or algorithms for intermediate certificate authority certificates for servers, and consequently device103may not be able to readily verify a certificate for server103such as cert.server101cwithout storing and using (x) and (y) above. The mutually authenticated ECDH key exchange with forward secrecy depicted inFIG.2aand subsequent Figures herein supports devices with those limitations. Other benefits are possible as well, such as faster and less resource-intensive authentication of a network105with device103.

After receiving message206a, server101can conduct a point validation step204afor received value or point X1211a. Note that point validation step204ais related to a key validation step204and can use several of the same sub-steps depicted and described for a key validation step204for server101above. A point validation step204ais different than a key validation step204since (i) the value X1211ais preferably not used as a public key to be shared with other parties, but rather (ii) represents a point on the ECC curve from parameters104athat will subsequently undergo a point addition operation in order to mutually derive a shared secret with device103. Further, point X1211acan be received through a secure session221with a trusted party comprising key server102, and thus the point X1211acan have a higher level of confidence or trust as being correct and properly formatted than a device ephemeral public key Ed103areceived potentially via the Public Internet. A point validation step204afor server101can comprise verifying that received point X1211ais on the ECC curve as specified in parameters104aand that the point is not the “point at infinity”. Other possibilities exist as well for conducting a point validation step204aon the received point X1211awithout departing from the scope of the present disclosure.

After conducting a point validation step204a, server101can then conduct an ECDH key exchange step212, where a key exchange step212is depicted and described in connection withFIG.2bbelow. In summary, server101can input (i) the server derived ephemeral private key e1101bfrom a step101xand (ii) the received device ephemeral public key Ed103afrom message203into an ECDH key exchange algorithm220(inFIG.2b) in order to calculate a point X2212a. Server101can then conduct a key derivation step213as depicted and described in connection withFIG.2bbelow. In summary, server101can conduct an ECC point addition step214(inFIG.2b) using both (i) point X1211afrom message206band (ii) point X2212afrom step212in order to mutually derive a shared secret X3213a. Shared secret X3213acan be input into a key derivation function in order to output a symmetric ciphering key K1216aand also optionally a MAC key.

Server101can then conduct a step207ato create a digital signature101s, using an elliptic curve digital signature algorithm (ECDSA) over the values of at least, in part, random number random1202aand random number random2205r. The ECDSA could use (i) the private key corresponding to the public key in certificate cert.server101cas (ii) the private key for creating digital signature101sin a step207a. The ECDSA can be compatible with IETF RFC 6979, IETF RFC 4574, and also related FIPS standards or other standards for digital signatures using ECC PKI keys. Additional data to sign for signature101sin a step207acould comprise the cryptographic parameters104aand the certificate cert.server101c. In addition, other digital signature algorithms besides ECDSA could be used in a step207asuch as the use of RSA based digital signature algorithms, or even post-quantum cryptography algorithms. If other digital signature algorithms besides ECDSA are used in a step207a, then the public key in certificate cert.server101cand corresponding private key can support the other digital signature algorithms. In general, the digital signature algorithms used to create digital signature101scan support cryptographic algorithms and PKI keys that are different than the set of cryptographic algorithms104in order to conduct a mutually authenticated ECDH key exchange with forward secrecy as contemplated herein.

Server101can then conduct an encryption step217(i) using the key K1216aoutput from key derivation step213in order to (ii) create a ciphertext1217b. Exemplary details for an encryption step217is depicted and described in connection withFIG.2cbelow, and an encryption step217can use a symmetric ciphering algorithm. The plaintext within ciphertext1217bcan comprise at least, in part, the random number random1202aand random number random2205r. Other data could be included in plaintext for ciphertext217bsuch as the certificate cert.server101c, digital signature101s, as well as parameters104a, without departing from the scope of the present disclosure. For some exemplary embodiments the use or inclusion of a certificate cert.server101cand digital signature101sfor plaintext in ciphertext217bcould be omitted, since the mutually derived symmetric ciphering key K1216acan be derived with authentication of server101and network105to device103.

Server101can then send device103a message206c, where the destination IP address and port number of message206ccan comprise the source IP address and port number203areceived with message203and recorded in server database101d. Message206ccan include the server ephemeral public key E1101aand the ciphertext1217b, as depicted inFIG.2a. The value “K1216a” depicted inFIG.2ais shown to illustrated that the derived symmetric ciphering key216afrom a key derivation step213is used to encrypt ciphertex1217b(indicated by the brackets shown inFIG.2afor message206c), and the value K1216ais not normally transmitted as plaintext or ciphertext in message206c. Ciphertext1217bcan include plaintext values of random number random1202a, parameters104a, certificate cert.server101c, random number random2205r, and signature101s. Other data could be included as plaintext in ciphertext217bsuch as extensions for a TLS or DTLS handshake, data supporting an application for device103, and other possibilities exist as well. As depicted inFIG.2a, the series of steps and messages beginning with step201afor device103though the receipt of message206cby device103can comprise a step222, where the combined step222can be used in additional embodiments depicted below.

As contemplated in the present disclosure, a message such as message206cand also other messages such as message203, message206a, etc. can be transmitted or sent in parts, where the data for the message can be transmitted and received in separate datagrams or portions over time. For these embodiments, the message can comprise the collection of separate datagrams or portions transmitted or sent separately. For example, with separate datagrams or portions for a message206cinFIG.2a, a first datagram or portion for message206ccould comprise server ephemeral public key E1101a, which could be sent (i) after a key pair generation step101x, and (ii) before receiving message206afrom key server102. A second datagram or portion for message206ccould comprise ciphertext1217b, which could be sent after server101receives message206afrom key server102. In this manner, by sending message206cas a first portion and a second portion, the overall speed of conducting a step223for device103could be increased. For example, by receiving the first portion of message206ccomprising key E1101a, device103could then (a) begin conducting steps below of204and218, while (b) waiting for the second portion of message206ccomprising ciphertext1217bto be sent separately and after the first portion. By increasing the overall speed for conducting a step223for device103, then electrical power consumption or battery usage for device103can be reduced. Other possibilities and benefits from sending a message in the present disclosure as a first portion and a second portion, without departing from the scope of the present disclosure. Messages depicted and described herein may be sent and received as multiple portions over time, where the message can comprise the collection of the multiple portions.

Device103can then receive message206cand conduct a series of steps in order to process the message. Device103can conduct a key validation step204in order to verify that server ephemeral public key E1101ain message206cis properly formatted and is a valid point on the named curve for parameters104a. Validation step204for device103can be equivalent to the validation step204for server101described above. Device103can then conduct an ephemeral ECDH (ECDHE) key exchange step218in order to mutually derive symmetric ciphering key K1216a. Details for an ECDHE key exchange step218is depicted and described in connection withFIG.2cbelow. In summary, device103, using parameters104a, can perform an elliptic curve point addition operation on (i) the server ephemeral public key E1101areceived in message206cand (ii) the recorded network static public key PK.network102a. Device103can input (i) the point derived from ECC point addition and (ii) the device ephemeral private key ed103binto an ECDH key exchange algorithm in order to mutually derive shared secret key X3215with server101. The mutual derivation of shared secret key X3215by server101is depicted and described in connection with key exchange step213for server101inFIG.2bbelow. Device103can input shared secret key X3215into a key derivation function in order to mutually derive symmetric ciphering key K1216a. Note that a MAC key could also be derived in step218.

Device103can then perform a decryption step219in order to decrypt ciphertext1217bfrom message206cusing the derived symmetric ciphering key K1216afrom the key exchange step218, where symmetric ciphering key K1216awas derived as described in the paragraph above. A decryption step219is also depicted and described in connection withFIG.2cbelow. Device103can then read the plaintext within ciphertext1217b, as well as verifying message integrity of ciphertext1217busing a MAC key derived in a step218. Device103in a decryption step219can read the plaintext values of random number random1202a, random number random2205r, and certificate cert.server101c, as well as a digital signature101s. Note that digital signature101scan be over at least the random number random1202athat device103sent in a message203.

At step208, device103can conduct a verification step for the plaintext certificate cert.server101cin order to validate the certificate. Device103in a step208can verify a signature from a certificate authority for the server static public key PK.server101pin the certificate (plus any intermediate certificate signatures) using a root certificate for the certificate authority. The root certificate for the certificate authority could be recorded in a nonvolatile memory for device103. Device103can verify both the certificate authority signature in cert.server101cusing an elliptic curve digital signature algorithm (ECDSA). The ECDSA could use a certificate authority public key for from a root certificate for verifying the certificate authority signature in a certificate cert.server101c. The ECDSA can be compatible with IETF RFC 6979, IETF RFC 4574, and also FIPS 186-4 standards or related and subsequent standards for digital signatures using ECC PKI keys.

Note that a certificate cert.server101ccould also specify parameters different than the use of an ECC algorithm, such as using RSA based signatures. For these embodiments using RSA based keys for digital signatures, device103could use a digital signature algorithm (DSA) and server static public key PK.server101pcan comprise an RSA-based key. Note that in some exemplary embodiments, the use of a server certificate cert.server101ccould be omitted, since device103can authenticate server101using the authenticated ECDH key exchange step218(where successful decryption of ciphertext1217bproves to device103that server101has access to SK.network102b). Further, a server certificate cert.server101ccould be included in a message206cand ciphertext1217b, but device103could omit a separate certificate verification step208and still trust the server public key PK.S1101pin a cert.server101c. In other words, successful decryption of the cert.server101cwith the symmetric ciphering key K1216acan signal or indicate that cert.server101ccan be trusted using the stored PK.network102a, since the cert.server101ccould only be encrypted by a server101with access to SK.network102b.

After a step208to verify certificate cert.server101c, device103can conduct a signature verification step209ato verify signature101s. For a step209, device103could use the server static public key PK.server101pfor server101from certificate cert.server101cand an ECDSA signature algorithm in order to verify signature101s. The signed data verified by a signature verification step209acan comprise at least, in part, both random number random1202afrom device103and random number random2205rfrom server101, as well as other data within message206csuch as certificate cert.server101c. If the signature verification step209afails, then device103can stop further processing of message206cand return an error message.

Device103can conduct a signature creation step207bin order to create digital signature103sover data received in message206c. The data signed by a signature creation step207bfor signature103scan comprise at least, in part, random number random2205r. A set of parameters104acan specify values and settings to utilize with an ECDSA in a step209a, such as a secure hash algorithm to utilize, the use of a deterministic ECC signature algorithm (avoiding the need to include a unique random number from device103with the signature103s), padding rules, encoding rules, etc. Device103can use device private key d1101din order to create signature103s.

Device103can then conduct an encryption step217c, where encryption step217ccan use the exemplary encryption step217depicted and described below inFIG.2cwith different plaintext data than the depicted data for a step217inFIG.2c. The encryption key for a step217ccan comprise the symmetric ciphering key K1216aderived by device103above in a step218, and a MAC key216b(fromFIG.2cbelow) can also be utilized. In some exemplary embodiments, the encryption step217ccan use a different symmetric ciphering key K1216athan key K1216aused by server101to encrypt ciphertext1217b. In other words, different symmetric ciphering keys could be used by (i) server101to encrypt ciphertext1217band (ii) device103to encrypt a ciphertext217d. However, both server101and device103can mutually derive the different symmetric ciphering keys using at least the mutually derived shared secret X3215. For some exemplary embodiments, the key K1216afrom a KDF216can comprise two portions, where (i) a first portion is used by server101to encrypt data and device103to decrypt data and (ii) a second portion is used by device103to encrypt data and server101to decrypt data.

The plaintext data for an encryption step217ccan comprise at least, in part, an identity for device103of ID.device103i, and the random number random2205rfrom server101. Other data could be included in the plaintext for an encryption step217cwithout departing from the scope of the present disclosure, such as, but not limited to, data from a transducer connected to device103. In addition, the device103static public key D1103c, or a certificate for device103with public key D1103ccould be included as plaintext data for an encryption step217c. The output of an encryption step217ccan comprise ciphertext2217d, as depicted inFIG.2a. As depicted and described in connection withFIG.2cbelow, the output of an encryption step217ccould also include an initialization vector and a MAC code, which could be included as metadata or plaintext along with ciphertext2217din a message210a. The initialization vector can be used to chain blocks in order to scramble data across the multiple blocks and the MAC code can be used to confirm message integrity using a MAC key output from key exchange algorithm218. For embodiments where server101could store or receive device static public key D1103cbefore receiving a message210a(such as receiving the key D1103cfrom a server associated with device103), then key D1103cand/or a certificate for device103could be omitted from ciphertext2217dand a message210a.

After step217c, device103can send server101a message210a, where message210acan include ciphertext2217c. In exemplary embodiments, message210ais transmitted by device103using the same source IP address and port number as message203. In addition, message210ais transmitted by device103using the same destination IP address and port number for server101as message203. Although the signature103sis depicted inFIG.2aas being internal to ciphertext2217c, in some exemplary embodiments signature103scan be external to ciphertext2217c. Likewise, although a signature101sis depicted as within a ciphertext217bfrom server101, in some embodiments a signature101scould be external to ciphertext217bin a message206c. Server101can receive message210aby listening to the same local IP address and port number used to receive message203above.

After server101receives message210a, server101can conduct a series of steps in order to process the message. Server101can conduct a decryption step219a, which can comprise a decryption step219depicted and described below in connection withFIG.2c, but with different ciphertext data. The ciphertext data for a decryption step219acan comprise the ciphertext2217creceived by server101in message210a. A decryption step219acan also use an initialization vector and MAC code received along with ciphertext2217cin message210a. After conducting a decryption step219a, server101can read the plaintext data within ciphertext2217c. In exemplary embodiments, the plaintext data can include an identity for device103of ID.device103i, the device static public key D1103c, and also the random number random2205r. Although not depicted inFIG.2a, ciphertext2217aas received by server101can include input from a transducer or sensor operated by device103, such as, but not limited to, keyboard input, temperature data from a thermocouple or thermistor, pressure data from a transducer, the state of an actuator, the state of an electronic switch, gate, or relay, etc. operated by device103. Other possibilities exist as well for transducer data in ciphertext2217awhich is decrypted into plaintext by server101in a decryption step219awithout departing from the scope of the present disclosure.

At step210b, server101can process the plaintext data output from a decryption step219a. Server101can read and record the device identity ID.device103ifor use in subsequent messages. Server101can read the value for random number random2205rto confirm the value or number equals the random number random2205rsent above in message206c. In exemplary embodiments, server101can record the plaintext data decrypted from ciphertext2217cin a server database101dalong with a timestamp, after completing the signature verification step209c. Server101can conduct a signature verification step209bfor signature103susing the same signature verification algorithm and parameters as signature verification step209a, except using the device static public key D1103c. Parameters104can specify settings or values for conducting a signature verification step209a. In exemplary embodiments, signature verification step209bcomprises an ECDSA signature verification for digital signature103susing key D1103c. Note that signature103sis over data that includes at least random number random2205rsent by server101in message206c. Device static public key D1103ccould be recorded in nonvolatile memory or disk storage of server101as depicted inFIG.1babove.

Upon successful completion of a signature verification step209bfor digital signature103s, server101and device103can conduct additional steps to securely transfer data106between the two nodes. Although not depicted inFIG.2a, server101could send device103commands, files, configuration data, or other data using ciphertext encrypted with derived symmetric ciphering keys. Server101and device103could also update key K1216aor rotate key K1216ausing a key derivation function (such as key derivation function216depicted inFIG.2bandFIG.2cbelow). As depicted inFIG.2a, after a step210band a step209b, server101can send key server102a message210b, where message210bcan include the device identity ID.device103iand an “OK” message, where the “OK” signals to key server102that server101and device103have successfully derived and used symmetric ciphering key216ausing PKI keys and an ECDH point addition of shared secret X1211aand X2212a. As depicted inFIG.2a, the series of steps beginning with a step204for device103through the receipt of message210bcan collectively comprise a step223.

FIG.2bis a flow chart illustrating exemplary steps for conducting a key exchange using PKI keys in order to derive shared secrets, and for conducting a key derivation function using the derived shared secrets, in accordance with exemplary embodiments. Key server102can conduct a key exchange step211in order to derived a secret key X1211a. Server101can conduct a key exchange step212in order to derive a secret key X2212a. Server101can receive the secret key X1211ain a message206bfrom key server102inFIG.2aabove through a secure connection221. Server101can then conduct a key derivation function213using shared secrets X1211aand X2212ain order to derive a symmetric ciphering key K1216a. Using the methods and ECC PKI keys described in the present disclosure, a device103can also derive the same symmetric ciphering key K1216aas depicted and described below for a key exchange step218inFIG.2c. In other words, for exemplary embodiments (i) the corresponding key exchange step218(inFIG.2cbelow) for a device103by network105can be (ii) shared or distributed between a server101and key server102in order to secure or isolate network static private key SK.network102b.

The processes and operations, described below with respect to all of the logic flow diagrams and flow charts may include the manipulation of signals by a processor and the maintenance of these signals within data structures resident in one or more memory storage devices. For the purposes of this discussion, a process can be generally conceived to be a sequence of computer-executed steps leading to a desired result.

These steps usually require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, or otherwise manipulated. It is convention for those skilled in the art to refer to representations of these signals as bits, bytes, words, information, elements, symbols, characters, numbers, points, data, entries, objects, images, files, or the like. It should be kept in mind, however, that these and similar terms are associated with appropriate physical quantities for computer operations, and that these terms are merely conventional labels applied to physical quantities that exist within and during operation of the computer.

It should also be understood that manipulations within the computer are often referred to in terms such as listing, creating, adding, calculating, comparing, moving, receiving, determining, configuring, identifying, populating, loading, performing, executing, storing etc. that are often associated with manual operations performed by a human operator. The operations described herein can be machine operations performed in conjunction with various input provided by a human operator or user that interacts with the device, wherein one function of the device can be a computer.

In addition, it should be understood that the programs, processes, methods, etc. described herein are not related or limited to any particular computer or apparatus. Rather, various types of general purpose machines may be used with the following process in accordance with the teachings described herein.

The present invention may comprise a computer program or hardware or a combination thereof which embodies the functions described herein and illustrated in the appended flow charts. However, it should be apparent that there could be many different ways of implementing the invention in computer programming or hardware design, and the invention should not be construed as limited to any one set of computer program instructions.

Further, a skilled programmer would be able to write such a computer program or identify the appropriate hardware circuits to implement the disclosed invention without difficulty based on the flow charts and associated description in the application text, for example Therefore, disclosure of a particular set of program code instructions or detailed hardware devices is not considered necessary for an adequate understanding of how to make and use the invention. The inventive functionality of the claimed computer implemented processes will be explained in more detail in the following description in conjunction with the remaining Figures illustrating other process flows.

Further, certain steps in the processes or process flow described in all of the logic flow diagrams below must naturally precede others for the present invention to function as described. However, the present invention is not limited to the order of the steps described if such order or sequence does not alter the functionality of the present invention. That is, it is recognized that some steps may be performed before, after, or in parallel other steps without departing from the scope and spirit of the present invention.

The processes, operations, and steps performed by the hardware and software described in this document usually include the manipulation of signals by a CPU or remote server and the maintenance of these signals within data structures resident in one or more of the local or remote memory storage devices. Such data structures impose a physical organization upon the collection of data stored within a memory storage device and represent specific electrical or magnetic elements. These symbolic representations are the means used by those skilled in the art of computer programming and computer construction to most effectively convey teachings and discoveries to others skilled in the art.

A key exchange step211for key server102to derive a secret key X1211acan utilize a selected set of cryptographic parameters104aas depicted and described in connection withFIG.1aandFIG.2aabove. As depicted inFIG.2b, an key exchange algorithm220in step211for key server102can receive input both of device ephemeral public key Ed103aand network static private key SK.network102b. The key exchange algorithm220could comprise a Diffie Hellman key exchange (DH), an Elliptic Curve Diffie Hellman key exchange (ECDH), and other possibilities exist as well without departing from the scope of the present invention. A key exchange algorithm220can support either PKI keys based on elliptic curves or RSA algorithms, although support of elliptic curves may be preferred in some exemplary embodiments due to their shorter key lengths and lower computational processing requirements.

A summary of ECDH as a key exchange algorithm220is included in the Wikipedia article titled “Elliptic Curve Diffie-Hellman” from Mar. 9, 2018, which is herein incorporated by reference. An exemplary embodiment of key exchange algorithm220could comprise a “One-Pass Diffie-Hellman, C(1, 1, ECC CDH)” algorithm as described in section 6.2.2.2 on page 81 of the National Institute of Standards and Technology (NIST) document “NIST SP 800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” from March, 2007 which is hereby incorporated by reference its entirety. Other key exchange algorithms in NIST SP 800-56A could be utilized as well for a key exchange algorithm220inFIG.2aandFIG.2bwithout departing from the scope of the present disclosure. Example calculations for an ECDH key exchange for a key exchange algorithm220are shown below inFIG.2c.

Other algorithms to derive a secret keys using public keys and private keys may also be utilized in a key exchange algorithm220, such as, but not limited to, the American National Standards Institute (ANSI) standard X-9.63. Cryptographic parameters104acan also include information, values, or settings for conducting (i) a key exchange algorithm220in step211and step212and (ii) a key derivation function216in order to derive a commonly shared symmetric encryption key K1216a. As contemplated herein, the terms “selected set of cryptographic parameters104a” and “cryptographic parameters104a”, and “parameters104a” can be equivalent, and can also comprise a subset of exemplary cryptographic parameters depicted and described in connection withFIG.1aandFIG.2dbelow. Parameters104ainput into a key exchange algorithm220can include a time-to-live for a key K1216athat is derived, a supported point formats extension, where the supported point formats extension could comprise uncompressed, compressed prime, or “compressed char2” formats, as specified in ANSI X-9.62. In other words, (i) an ECC keys input into a key exchange algorithm220and (ii) secret keys output from key exchange algorithm220may have several different formats and a set of parameters104acan be useful to specify the format. As depicted inFIG.2b, the output of a key exchange algorithm220in a step211, such as an ECDH key exchange, can comprise a secret value X1211a. In exemplary embodiments, secret value X1211acan comprise a point on an elliptic curve, where the equation and values for the elliptic curve can be specified in parameters104a. As contemplated herein, the secret value X1211a(as well as X2212abelow) comprises both an X coordinate and a Y coordinate, in order to support subsequent ECC point addition operations.

Key exchange step212for a sever101depicted inFIG.2acan correspond to key exchange212inFIG.2b. Key exchange step212can comprise inputting or using the device ephemeral public key Ed103a(from message203inFIG.2a) and the server ephemeral private key e1101b(from a key generation step101x) into a key exchange algorithm220, which can comprise the same or equivalent key exchange algorithm220depicted and described in connection with key exchange step211described above. Other elements or algorithms within a key exchange step212can be equivalent to a key exchange step211above, including the use of shared parameters104a. The output of a key exchange algorithm220in a step212can comprise a secret key or value X2212a. In exemplary embodiments, secret value X2212acan comprise a point on an elliptic curve, where the equation and values for the elliptic curve can be specified in parameters104a. Exemplary numeric values for using a key exchange algorithm220are depicted and described below, and key exchange algorithm220can utilize an ECC point multiplication of a public key by the scalar value of a private key. In exemplary embodiments, a server101can record the value X2212aderived from a step212and also the value X1211areceived in a message206bin a server database101d. The time the values are stored in a server database101dcan be minimized in order to increase security, and, for example, the recording of the values can be deleted before server101sends the “OK” message210bto key server102inFIG.2a.

A key derivation step213for server101can (i) combine the output of key exchange steps211and212in order to calculate or derived the shared secret X3215and then (ii) perform a key derivation function step216on the derived or calculated shared secret X3215in order to determine or calculate shared secret key K1216a, which can comprise a symmetric ciphering key. Note that shared secret key K1216acan be also mutually derived by device103, where device103uses the key exchange step218depicted and described in connection withFIG.2cbelow. In exemplary embodiments, a server101can conduct the key derivation step213using (i) the value X1211areceived from key server102(where receipt of X1211aby server101can be in a message206bas shown inFIG.2aabove), and (ii) the value or key X2212aoutput from a key exchange step212for server101in the paragraph above. As contemplated herein, the values of X1211a, X2212a, and X3215may be described as either “shared secrets” or “shared secret keys”. Although the values may not normally be used as a key directly with a symmetric ciphering algorithm, these values and the output of a key exchange algorithm220can comprise a secret or a key.

Key derivation step213for server101can comprise two primary steps. A first step in key derivation213can comprise an ECC point addition214on the value X1211aand the value X2212a. The result of the ECC point addition will be equal to the value X3215. Note that device103can also derive the same value for value X3215(in step218below) without ECC point addition214using a step218. In other words, although (a) the related key exchange step218for device103may include a point addition for public keys, (b) the key exchange step218for device103will not use ECC point addition for points derived from two separate private keys in two separate servers (e.g. X1211auses private key SK.network102band X2212auses private key e1101b).

Exemplary calculations for an ECC point addition214can comprise the calculations shown for point addition in the Wikipedia article for “Elliptic Curve Point Multiplication” dated May 15, 2018, which is herein incorporated by reference in its entirety. As depicted inFIG.2b, (a) the calculation of X3215by server101using an ECC point addition214over X1211aand X2212awill equal (b) the value for X3215calculated by device103using a key exchange algorithm220in a step218fromFIG.2cbelow. A second step in key derivation step213as depicted inFIG.2bcan comprise a key derivation function step216using (a) input from ECC point addition step214(e.g. value X3215output from step214), where (b) the output of key derivation function step216can comprise key K1216aand also an associated MAC key216b. In exemplary embodiments, the X coordinate from shared secret X3215can be used with key derivation function216.

By server101conducting a key derivation step213as depicted inFIG.2b(where key server102conducts the calculations for step211using the network static private key SK.network102b), (i) sever101can calculate symmetric ciphering key K1216awithout recording or operating on the network static private key SK.network102b. In this manner, the security of a system100or system200can be significantly enhanced, since the network static private key102bdoes not need to be recorded or operated by server101, which can communicate with a plurality of devices103over an IP network. In other words, by server101(i) using the ECC point addition over key X1211ainstead of (ii) conducting a key exchange220directly with SK.network102b, then server101does not need to record or operate with the network static private key SK.network102b, thereby increasing security. Also, since (i) key X1211acan be the equivalent of an ECC public key as a point on an elliptic curve, and (ii) it is not computationally feasible to determine network static private key SK.network102bfrom key X1211a, then key X1211adoes not reveal meaningful information about network static private key SK.network102b.

Many benefits can be achieved by server101conducting a key derivation step213using key X1211ainstead of recording and operating with network static private key SK.network102b. As one example, the corresponding network static public key PK.network102acould potentially be both (i) recorded in millions of distributed devices connecting to server101through many different physical locations and networks, and (ii) used for a decade or longer. Keeping network static private key SK.network102bsecure for this embodiment could be economically essential, since a compromise of network static private key SK.network102bmay (i) render the devices103insecure (or unable to authenticate network105using an ECDHE key exchange), and (ii) require the secure distribution or re-installation of a new, different network static public key SK.network102ain the devices, which may not be economically feasible due to the prior distribution of devices.

Exemplary data and numbers can be provided to demonstrate the calculations for (i) key exchange step211, (ii) key exchange step212, and (iii) key derivation step213using an ECC point addition214. The exemplary data can comprise decimal numbers for the example ECC PKI keys and exchanged keys listed in “Test vectors for DPP Authentication using P-256 for mutual authentication” on pages 88 and 89 of the DPP specification version 1.0. Parameters104acan comprise the elliptic curve of “secp256r1” with key lengths of 256 bit long keys.

The network static private key SK.network102bcan comprise the exemplary following number, and can be recorded in key server102:

The server ephemeral private key e1101bcan comprise the exemplary following number, and can be recorded by server101:

The device ephemeral public key Ed103acan comprise the following exemplary values with X and Y numbers (or “coordinates”) of:

Key exchange step211for an ECDH algorithm key exchange220by key server102can input the device ephemeral public key Ed103aand the network static private key SK.network102b(both with numbers above) in order to calculate a secret X1211a. An exemplary number or value for secret X1211afrom the values above using parameters104acan be:

Key exchange step212for an ECDH algorithm key exchange220by server101can input the device ephemeral public key Ed103aand the server ephemeral private key e1101b(both with numbers above) in order to calculate a secret X2212a. An exemplary number or value for key X2212afrom the values above using parameters104acan be:

An ECC point addition213for the above two derived points (or “keys”) X1211a(from keys Ed103aand SK.network102b) and X2212a(from keys Ed103aand e1101b) will result in the following point that also equals X3215.

Note that the same numeric value for key X3215can also be derived by device103from a key exchange step218below using ECDH key exchange algorithm220a. For exemplary embodiments, although private key SK.network102band ephemeral private key e1101bare recorded and operated by physically separated devices, device101can record and operate on the corresponding public keys PK.network102aand ephemeral public key E1101a(at the same physical location as device103).

After an ECC point addition213, for a key derivation step218inFIG.2b, server101can input the shared secret key X3215, where key X3215was output from the ECC point addition214, into a key derivation function216. The key derivation function216can comprise the same key derivation function216used by a device103in a step218below. The output of a key derivation function216can comprise both (i) a symmetric ciphering key K1216aand (ii) a MAC key216b. MAC key216bcan be used with a symmetric ciphering algorithm in order to generate a MAC code, such that the other party using the same key K1216aand MAC key216bcan process the ciphertext and calculate the same MAC code in order to verify message integrity.

Key derivation function216can use a secure hash function such as, but not limited to, SHA-256, SHA-384, SHA-3, etc. and additional values such as a text string with secret X3215. The specification of a secure hash algorithm and the text string for use with a key derivation function216could be commonly shared between server101and device103by commonly shared parameters104a. In some exemplary embodiments, the text string for use with secret X3215can be from data, text, or values transmitted in (i) message203(for KDF216by server101in step213) and/or (ii) message206c(for KDF216by device103in step218). The output of a secure hash algorithm within a key derivation function216could have a subset of bits selected or possibly a secure hash expanded in order to obtain the number of bits required for a symmetric key with a symmetric ciphering algorithm, such as key K1216a. A key derivation function (KDF)216could comprise a KDF compatible with or specified by ANSI standards for “X9.63 Key Derivation Function”. Other possibilities exist for a key derivation function216to convert a secret X3215into a symmetric ciphering key K1216aand a MAC key216bwithout departing from the scope of the present disclosure. As contemplated in the present disclosure, although an ECC public key such as secret X3215can comprise a coordinate with an X value and a Y value, in exemplary embodiments a single number comprising the X value can be selected and input into a key derivation function216. In addition, the key K1216acan comprise two portions, where (i) a first portion can be a key for encrypting data by server101and decrypting the data by device103and (ii) a second portion can be a key for encrypting data by device102and decrypting the data by server101.

FIG.2cis a flow chart illustrating exemplary steps for conducting a key exchange using PKI keys in order to derive a shared secret key, and for using the derived shared secret key to encrypt and decrypt data, in accordance with exemplary embodiments. Exemplary steps for a device103to mutually derive a shared secret X3215and symmetric key216acan comprise a key exchange step218. Exemplary steps inFIG.2cfor a server101to encrypt plaintext data using the mutually derived symmetric key216acan comprise an encryption step217. Exemplary steps inFIG.2cfor a device103to decrypt ciphertext data using the mutually derived symmetric key216acan comprise a decryption step219. The use of the steps for a key exchange218, encryption217, and decryption219were also depicted and described in connection withFIG.2aabove. Note that steps inFIG.2cand the steps inFIG.2bcan share some algorithms and values, and the descriptions for the algorithms and values inFIG.2abcan be applicable forFIG.2c. For example, the key exchange algorithm220acan comprise an ECDH key exchange equivalent to key exchange step220. The set of parameters104adepicted and described inFIG.2bcan also be used inFIG.2c.

A device103can conduct a key exchange step218. At step218, (i) a combination of a recorded network static public key PK.network102aand received server ephemeral public key E1101a, and (ii) the derived device ephemeral private key ed103bcan be input into an ECDH key exchange algorithm220ain order to calculate the shared secret X3215. The recorded network static public key PK.network102aand received server ephemeral public key E1101acan be combined via elliptic curve point addition. Exemplary data and numbers can be provided to demonstrate the calculations for (i) key exchange step218. The exemplary data can comprise decimal numbers for the example ECC PKI keys and exchanged keys listed in “Test vectors for DPP Authentication using P-256 for mutual authentication” on pages 88 and 89 of the DPP specification version 1.0. Parameters104acan comprise the elliptic of “secp256r1” with key lengths of 256 bit long keys.

The device ephemeral private key ed103bcan comprise the exemplary following number, and can be recorded in device103after a key pair generation step103xfromFIG.1aabove:

The network static public key PK.network102acan comprise the exemplary values with X and Y numbers (or “coordinates”) of:

The server ephemeral public key E1101acan comprise the following exemplary values with X and Y numbers (or “coordinates”) of:

An ECC point addition for the above two keys E1101aand PK.network102awill result in the following exemplary point. which comprises (a) both E1101aand PK.network102afor a key exchange step218then (b) input into an ECDH key exchange algorithm220a:

The above combination of both E1101aand PK.network102afor a key exchange step218via an ECC point addition operation is depicted inFIG.2cwith the “+” symbol between the public keys.

The output of the above ECC point addition for public keys E1101aand PK.network102acan be input into ECDH key exchange algorithm220ausing parameters104a. All of the exemplary calculations for a key exchange step218can use the exemplary subset of cryptographic parameters104a. An ECDH algorithm key exchange220ain key exchange step218can input (i) the exemplary point immediately above from the ECC point addition operation on the public keys101aand102aand (ii) the device ephemeral private key ed103binto the ECDH key exchange220a, and output the point X3215. Note that the secret X3215as derived by device103in a key exchange step218equals or is the same numeric value as the secret X3215derived by server101in a key derivation step213inFIG.2b. An exemplary number or value for secret X3215calculated by device103using a key exchange step218using the above exemplary numeric values for ed103b, PK.network102a, and E1101awould be:

AlthoughFIG.2cdepicts an ECC point addition operation over public keys E1101aand PK.network102a, the same shared secret value X3215could be generated or derived by conducting (i) a first ECC point multiplication operation with the server ephemeral public key E1101aand the device ephemeral private key ed103bto derive a first point, and (ii) a second ECC point multiplication operation with the network ephemeral public key PK.network102aand the device ephemeral private key ed103bto derive a second point, and (iii) an ECC point addition operation with the first point and the second point to derive the shared secret value X3215. In other words, the value X3215can be calculated as either:
X3 215=[E1 101a+PK.network 102a]*ed103b, or  (i)
X3 215=[E1 101a*ed103b]+[PK.network 102a*ed103b]  (ii)

For a key derivation step218, derived shared secret key X3215can be input into a key derivation function216where the key derivation function216can be equivalent to the key derivation function216depicted and described in connection withFIG.2babove for a key derivation step213. Note that for key derivation steps in the present disclosure, the X coordinate of a derived shared secret can be taken or used as input into the key derivation function. The output of a key derivation function216can comprise both (i) a symmetric ciphering key K1216aand (ii) a MAC key216b. MAC key216bcan be used with a symmetric ciphering algorithm in order to generate a MAC code, such that the other party using the same key K1216aand MAC key216bcan process the ciphertext and calculate the same MAC code in order to verify message integrity. The use of key K1216aand MAC key216bare described in connection with encryption step217and decryption step219.

Server101can conduct an encryption step217, where the use for an encryption step217is depicted and described in connection withFIG.2aabove. Plaintext217ain a step217can comprise the first random number random1202afrom device103, the second random number random2205r, and the server certificate cert.server101c. Other or different exemplary data could be included as plaintext217ain an encryption step217, including extensions for a TLS or DLTS handshake. The symmetric ciphering key for encryption step217can comprise symmetric key K1216afrom a key derivation step213and a MAC key216bcan be input into a symmetric ciphering algorithm225as well. Encryption step217and decryption step219can use a common symmetric ciphering algorithm225, which could comprise the Advanced Encryption Standard with Synthetic Initialization Vectors (AES-SIV) (and deciphering algorithm) also with a common set of symmetric ciphering parameters104ffrom a set of cryptographic parameters104. Other or different symmetric ciphering algorithms225could be utilized as well, such as, but not limited to such as AES, Triple Data Encryption Standard (3DES), Blowfish, or related algorithms. A mutually derived symmetric ciphering key K1216acan comprise two portions, where a first portion is used by server101for encryption and a second portion is used by device103for encryption. At least the first portion of key K1216acan be used in an encryption step217.

Symmetric ciphering parameters104fcan also specify the use of a block chaining mode such as cipher block chaining (CBC), counter mode (CTR), or Galois/Counter mode (GCM) and other possibilities exist as well. In addition, symmetric ciphering parameters104fcould specify a mode for message authentication, which could comprise a CMAC mode as specified in NIST publication SP-800-38B. In some exemplary embodiments, a symmetric ciphering algorithm225can comprise the AES-SIV algorithm as specified in IETF RFC 5297. The output from an encryption step217using a symmetric ciphering algorithm225and the depicted values input can be ciphertext217b, as depicted inFIG.2c.

A decryption step219can be performed by device103. A decryption219step converts the ciphertext217breceived in a message206cfromFIG.2ainto plaintext217a. Decryption step219can utilize a symmetric decryption algorithm225, which could comprise the same algorithm used in symmetric encryption algorithm225except the algorithm being used for decryption instead of encryption. Note that the same values are input into symmetric decryption algorithm225as symmetric encryption algorithm225above, such as symmetric encryption key K1216a(or the first portion of key K1216aif a second portion of key K1216ais used by device103for encryption) and parameters104fin order to convert ciphertext217bback into plaintext217a. Additional data input into symmetric decryption algorithm211bcan comprise an initialization vector217iand MAC code216cwhich could be sent along with ciphertext217b.

Device103can the read and process plaintext217aafter a decryption219step. The plaintext217aas read by device103can comprise the first random number random1202afrom device103, the second random number random2205r, and the server certificate cert.server101c. In exemplary embodiments, the successful decryption of a ciphertext into a plaintext using decryption algorithm225supports one-way authentication of the server101and/or network105, since successful decryption by device103can only take place when the server101has access to network static private key SK.network102b. In other words, only the nodes could mutually derive key K1216ainFIG.2bandFIG.2cby (i) device103recording PK.network102aand (ii) server101having access to SK.network102b(via key server102). Thus, data that is successfully encrypted by the server101and decrypted by the device103using key K1216awould confirm the server101is authenticated.

As depicted and described in connection withFIG.2a, server101or device103can also conduct both an encryption step217and a decryption step219. The steps for server101to conduct a decryption step219for can comprise step219aas depicted and described inFIG.2a. When server101conducts decryption step219ausing symmetric encryption key K1216a, the ciphertext and plaintext will comprise different values than those depicted inFIG.2c, where the ciphertext for a decryption step219acan comprise ciphertext2217d. Further, a device103can conduct an encryption step217cin with key K1216ain order to create ciphertext217d, as depicted inFIG.2a.

FIG.2dis an illustration of an exemplary server database and an exemplary set of cryptographic parameters, in accordance with exemplary embodiments. A server database101ddepicted and described above in connection with system100and system200can record data for server101to work with a plurality of devices103and at least one key server102. A server database101dcould record in at least one set of values, keys, and/or numbers for a plurality of devices103. Other possibilities exist as well for the organization, tables, and recorded data within a server database101dwithout departing from the scope of the present disclosure. Data within server database101dcould be encrypted using a symmetric key. Although system100and system200depict a server database101das operating or recorded within a server101, a server database101dcould comprise a separate server within a network105and communicating with server101via a secure session221or a private network107a. Further, a server database101d, when operating or recorded in a separate server than server101, then server database101dcould contain electrical components equivalent to a server101depicted and described in connection withFIG.1b.

Server database101dcan record values or numbers for a first random number random1202a, received device ephemeral public key Ed103a, a selected set of cryptographic parameters104a, a source IP address and port number203areceived for message203, a secure hash value over PK.network102acomprising H(PK.network102a)250, and identity for key server102comprising ID.key-server102i, an ECC point value X1211a, a server ephemeral public key E1101a, a server ephemeral private key e1101b, an ECC point value X2212a, an ECC point value X3215, a derived symmetric ciphering key K1216a, and a second random number random2205r. In exemplary embodiments, the values depicted in the first row of server database101dcould comprise data recorded by a server101while conducting the series of steps for a step222and step223depicted and described in connection withFIG.2aabove with a first device103. The values depicted in the second row of server database101dcould comprise data recorded by a server101while conducting the series of steps for a step222and step223depicted and described in connection withFIG.2aabove with a second device103, etc.

In exemplary embodiments for a server database101d, a first device103could send server101a first value for device ephemeral public key Ed103a, and the first value is depicted inFIG.2das “103a-1”. Since server101could communicate with a plurality of devices103, the second row in the depicted server database101dcould comprise data for the equivalent steps conducted with a second device103, such as recording a second value for device ephemeral public key Ed103afor the second device. The second value for device ephemeral public key Ed103awith the second device103is depicted inFIG.2das “103a-2”. Equivalent notations for other keys or values are applicable as well, such as server database101drecording a first secret X1211adepicted as “211a-1” for a first device103, and then recording a second secret X1211adepicted as “211a-2”. Thus, as depicted a server database101dcan record and operate with a plurality of different values for a key, where each are utilized by a different device. Although not depicted inFIG.2d, a server database could record device identity ID.device103ias well. For embodiments where a device identity103iis not available, then server101could keep track of different devices103for conducting the steps inFIG.2aby the source IP:port number203a.

In some exemplary embodiments, a message203can include a secure hash value H(PK.network102a)250, as described for a message203inFIG.2aabove. The receipt of a secure hash value H(PK.network102a)250could be mapped to or associated with a key server102via a key server identity ID.key-server102i, where the mapping of H250to ID.key-server102icould be recorded in a server database101dbefore device103sends a message203. For these embodiments and after receipt of message203, server101could conduct a query of server database101dusing the received H250in a message203in order to select a key server102with ID.key-server102iin order to send the message206ato key server102. In this manner, server101can communicate with a plurality of different key servers102, and the destination of a message206a(or key server102) can be selected by the value H250received in a message203. In other words, for a plurality of different devices103communicating with a server101, a first subset of devices103could record and use a first network static public key PK.network102a, and a second subset of devices103could record and use a second network static public key PK.network102a. By receiving a value or identifier of the first or second key102ain message203(such as H(PK.network102a)250), server101could use the data depicted for a server database101dto select or identify the correct key server102in order to (i) send a message206aand (ii) receive the correct secret X1211afor the device103using a particular PK.network102a.

Although the value H(PK.network102a)250is depicted as recorded in a server database101dinFIG.2d, a different value or identifier for the PK.network102acould be recorded and utilized as well. In an exemplary embodiment, server101could receive the plaintext PK.network102ain a message203and record the plaintext PK.network102ain a server database101d(instead of a hash value H250). In another exemplary embodiment, an identity for key server102(such as ID.key-server102i) could be selected or determined by server101using the selected set of cryptographic parameters104areceived in message203and recorded in a database101d. For these embodiments, a first selected set of cryptographic parameters104acould be associated with a first key server102(and first ID.key-server102i) and a second set of cryptographic parameters104acould be associated with a second key server102(and second ID.key-server102i). Other possibilities exist as well for a server database101dto record data in order to select a key server102for sending message206awith device ephemeral public key Ed103abased on data received in message203, without departing from the scope of the present disclosure. As one example, the identity for key server102of ID.key-server102icould be included in message203and the value for ID.key-server102icould be recorded in a server database101dby server101.

In a server database101d, although separate values are depicted for some data, such as values “102i-1” and “102i-2” for identities of key servers102, some of the exemplary values can comprise identical strings or numbers. For example, data for two different devices103in a server database101dcould record the same name or value of “102i-2” for a single key server102to be associated with the two different devices103. Likewise, two different devices103could share the same network static public key PK.network102a, and thus H250can be the same value of an exemplary “250-2” for two different devices103. A server database101dcould also record additional data and values than those depicted inFIG.2dfor some exemplary embodiments. For example, server database101dcould record timestamps for when messages are transmitted or received, such that stale or data older than a specified range could be purged. Server database101dcould also record data received from device103in a message210a, which could include data from a transducer operated by device103.

Some data within a server database101dcould be recorded and operated on separately by server101, such as server101not recording secrets such as X1211aor X2212a, etc. in a database101d, but rather server101could record the values in volatile memory101fof server101. In exemplary embodiments, server database101dcould also operate in a distributed or “cloud” configurations such that multiple different servers101could query and record data in server database101d, where data for server database101dis recorded in multiple, physically separated servers.

Cryptographic parameters104can specify sets of cryptographic parameters that are supported by server101in order to process message203and send response message206cfromFIG.2a. Cryptographic parameters104can be recorded in a server database101d, or in other locations within a system100and system200. As depicted inFIG.1a, each of device103, server101, and key server102can record and operate with a set of cryptographic parameters104. Cryptographic parameters104can record a collection of cryptographic algorithms or specifications such as a set identifier104a, a key length104b, an ECC curve name104c, a hash algorithm104d, symmetric ciphering key length104e, settings for a symmetric ciphering algorithm104f, and a random number length104g.

As contemplated herein, when a selected set of cryptographic parameters such as using the words or description “parameters104a” or “cryptographic parameters104a” can specify a row of parameters or values in a set of cryptographic parameters104, such that the collection of values in the row can be used with key pair generation functions101xand103x, ECDH key exchange220, and other cryptographic operations and steps as contemplated herein. Set identifier104acan be an identity for a row or set of values for cryptographic parameters104. For example, set “A” can comprise cryptographic suite 1 as specified in section 3.2.3 of DPP specification version 1.0. Key length104bcan be the length of keys in bits for PKI keys used in system100and system200. ECC Curve name104ccan be a name for an ECC curve used with PKI keys and key exchange algorithms in system100and system200.

Hash algorithm104din cryptographic parameters104can be the name of a secure hash algorithm, such as the exemplary SHA-256 algorithm depicted, which may also be referred to as “SHA-2”. Hash algorithm104dcan also be used in a key derivation function (e.g. KDF216above inFIG.2bandFIG.2c) and also with digital signature steps207aand209a. Settings for a symmetric ciphering algorithm104fcan specify the identity or name of a symmetric ciphering algorithm225such as “AES”, “AES-SIV”, 3DES, Blowfish, etc. Random length104gcan specify the length in bits for random numbers or “nonces” generated by both device103and server101, where the nonces can be used to prevent replay attacks and require messages transmitted and received to be unique. Other possibilities exist as well for data within cryptographic parameters104, such as the specification of point compression, encoding rules such as distinguished encoding rules (DER), ASN or CSN syntax notation, padding rules, etc.

FIG.2eis a flow chart illustrating exemplary steps for conducting a key exchange using PKI keys in order to derive a shared secret key using ECC point multiplication, in accordance with exemplary embodiments. An ECDH key exchange step218ncan be conducted by a device103, and use the steps for an ECDH key exchange step218, with the additional steps of conducting an ECC point multiplication using numbers N1298and N2299. A key derivation step213ncan be conducted by a server101, and use the steps for a key derivation step213, with the additional steps of conducting an ECC point multiplication using the same numbers N1298and N2299. In other words, (i) ECDH key exchange step218can comprise the depicted ECDH key exchange step218nwhere the numbers for N1298and N2299are equal to the value of “1”, and (ii) key derivation step213can comprise the depicted key derivation step213nwhere the numbers for N1298and N2299are also equal to the value of “1”. In some exemplary embodiments, (i) an ECDH key exchange step218depicted and described in connection withFIG.2afor device103can comprise the ECDH key exchange step218nwith point multiplication, and key derivation step213for server101can comprise the key derivation step213nwith point multiplication. The set of parameters104afrom figures above, such as withFIG.2a, can be used with both ECDH key exchange step218nand key derivation step213n.

A device103can conduct a key exchange step218n. At step218n, a device103can conduct a first ECDH key exchange step220and a second ECDH key exchange step220. For a step218n, a first ECDH key exchange step220can be conducted by device103with (i) the server ephemeral public key E1101areceived in a message206cfromFIG.2aand (ii) the recorded device ephemeral private key ed103b, and the resulting point multiplied by the number N1298. Note that the ECC point resulting from the first ECDH key exchange220in the previous sentence will also equal the point X2212amultiplied by the number N1298, where the calculation of point X2212ais depicted and described in connection with a key exchange step212inFIG.2b.

Continuing with step218n, a device103can conduct the second ECDH key exchange step220with (i) the network static public key PK.network102arecorded in device103and (ii) the recorded device ephemeral private key ed103b, and the resulting point multiplied by the number N2299. Note that the ECC point resulting from the second ECDH key exchange220in the previous sentence will also be equal to the point X1211amultiplied by the number N2299, where the calculation of point X1211ais depicted and described in connection with key exchange step211inFIG.2b.

Continuing with step218n, a device103can conduct an ECC point addition operation on the two points resulting from (i) the first ECDH key exchange step220multiplied by N1298and (ii) the second ECDH key exchange step multiplied by N2299. In other words, a device103can conduct an ECDH point addition operation with (i) the value X2212amultiplied by N1298and (ii) the value X1211amultiplied by the value N2299, in order to derive a secret X3′215athat is mutually shared with server101.

Exemplary data and numbers can be provided to demonstrate the calculations for (i) key exchange step218nand (ii) key derivation step213n. The exemplary data can comprise decimal numbers for the example ECC PKI keys and exchanged keys described above inFIG.2b. The first ECDH key exchange220for device103using (i) the exemplary numerical value for device ephemeral private key ed103binFIG.2cand (ii) the exemplary numerical value for server ephemeral public key E1101ainFIG.2c, using parameters104a, will result in the exemplary number or value for secret X1211a, where parameters104acan comprise the elliptic curve of “secp256r1” with key lengths of 256 bit long keys:

For an exemplary value of “3” for N1298, the resulting ECC point multiplication of X1211aby N1298with the value of “3” will result in the following point “3×X1”:

The second ECDH key exchange220for device103in a step218nusing (i) the exemplary numerical value for device ephemeral private key ed103binFIG.2cand (ii) the exemplary numerical value for network static public key PK.network102ainFIG.2c, using parameters104a, will result in the exemplary number or value for secret X2212a:

For an exemplary value of “7” for N2299, the resulting ECC point multiplication of X2212aby N2299with the value of “7” will result in the following point “7×X2”:

An ECC point addition for the two points “3×X1” and “7×X2” will result in the following point, which can equal the shared secret X3′215afor a key exchange step218n:

The above values for N1298and N2299are exemplary, and any numeric value less than the large prime number p for a named elliptic curve could be selected for both N1298and N2299.

Continuing with step218n, derived shared secret key X3′215acan be input into a key derivation function216where the key derivation function216can be equivalent to the key derivation function216depicted and described in connection withFIG.2babove for a key derivation step213. Note that for key derivation steps in the present disclosure, the X coordinate of a derived public key can be taken or used as input into the key derivation function. The output of a key derivation function216can comprise both (i) a symmetric ciphering key K1216aand (ii) a MAC key216b. The use of key K1216aand MAC key216bare described in connection with encryption step217and decryption step219inFIG.2c.

For a key derivation step213nby server101, server101can conduct the equivalent steps as key derivation step213inFIG.2b, with point multiplication operations depicted inFIG.2e. Server101can perform an ECC point addition and point multiplication step214ausing the values X1211aand X2212a, as well as the numbers N1298and N2299. The value X1211acould be received by server101from key server102in message206a. Note that the value X1211ais derived by key server102using an ECDH key exchange step211as depicted and described in connection withFIG.2b. A server101could calculate the value for X2212ausing an ECDH key exchange step212inFIG.2b. The value or point X1211acan be multiplied by number N2299. The value or point X2212acan be multiplied by the number N1298. An ECC point addition can be performed on the two ECC points obtained in each of the previous two sentences in order to calculate a value X3′215a. The exemplary calculations for point multiplication on X1211a(with N2299) and X2212a(with N2298) by device103would also be calculated by server101. In other words, the exemplary data and numbers depicted above for the calculations by device103could also be calculated by server101in order to mutually derive the same value for X3′215a. The mutually derived value for X3′215acan be input into key derivation function216in order to calculate a symmetric ciphering key K1216aand a MAC key216b, which can comprise the same numbers as calculated by device103in a step218n.

The source of values for N1298and N2299for both device103and server101could be mutually obtained in several ways. N1298and N2299could be recorded and shared with a set of cryptographic parameters104, such that selecting a subset of the cryptographic parameters104acould determine the values or numbers to use for N1298and N2299. In another exemplary embodiment, N1298and/or N2299could comprise pre-shared secret values or keys, such that device103receives the values in a secure manner before sending message203, such as, but not limited to, recording the values at functionally the same time network static public key PK.network102ais recorded in device103. Server101could receive the values N1298and N2299in a secure manner, such as from key server102in a secure session221. Other possibilities exist as well for a device103and a server101to obtain the numbers N1298and N2299without departing from the scope of the present disclosure. In exemplary embodiments, the number for N1298or N2299can be either equal, or the numbers could comprise different values.

A device103and a server101could also conduct a number derivation step297in order to obtain the numbers N1298and N2299, which is also depicted inFIG.2e. For a number derivation step297, a static public key can be input into a secure hash algorithm291, such as SHA-256. The static public key can be any public key shared between a device103and server101(e.g. where one node records the public key and the other node records the corresponding private key). In exemplary embodiments depicted inFIG.2e, the public key for a number derivation step297can comprise the network static public key PK.network102a, where a server101can derive or calculate the network static public key can be derived from the network static private key SK.network102busing parameters104. Other exemplary public keys shared between device103and server101can comprise any of public keys Ed103a, E1101a, D1103c, etc. The node recording the corresponding private key can calculate the public key using the parameters.

FIG.3ais a simplified message flow diagram illustrating an exemplary system with exemplary data sent and received by a mobile device, a g node b, and a key server, in accordance with exemplary embodiments. System301can include a mobile device103′, a “next generation node b”101′, and a key server102. Mobile device103′ can comprise a smart phone, a device for the “Internet of Things” (IoT), a tablet with a modem, or possibly a fixed station device that connects with a 5G or 6G network. Mobile device103′ can operate similar to a device103, with the additional functionality of connecting to a wireless network, where the network supports 3GPP standards and can also comprise a wide area network such as a public land mobile network. A “next generation node b”101′ (depicted as gNb101′) can contain the equivalent electrical components as those depicted for a server101inFIG.1b, except gNb101′ can also operate as a base transceiver station to send and receive data wirelessly with mobile device103′. The key server102could operate as part of an Authentication Server Function (AUSF) or equivalent functionality. Note that the distributed nature of the ECDH key exchanges as depicted inFIG.2aandFIG.2bandFIG.2chave benefits for the wireless WAN architecture inFIG.3a, SK.network102bfor a mobile device103′ does not need to be recorded or operated by a gNb101′

In exemplary embodiments, a mobile device103′, a gNb101′, and a key server102can conduct a step222′, where a step222′ can comprise primarily the step222as depicted and described inFIG.2a. There can be some differences between a step222and a step222′. Note that before the steps222′ depicted inFIG.3a, a mobile device103′ and a gNb101′ could conduct steps to establish communications between the nodes, such as recording parameters for RF communications by the mobile device103′ in a SIM card or eUICC. A mobile device103′ could also conduct steps to authenticate the network105operating a gNb101′. For a step222′, a mobile device103′ can send message203with the device ephemeral public key Ed103aand also an obfuscated identity for device103′, where the obfuscated identity can also comprise a temporary identity for device103. A gNb101′ can use the obfuscated identity to track the device103from a potential plurality of devices103communicating over a wireless network.

The gNb101′ can forward the device identity and the received device ephemeral public key to the key server102. The key server102can look up a unique key102vfor device103for the network static private key102bcorresponding to the network static public key102arecorded by the device103. The key server102can calculate value X1211aas depicted inFIG.2b, and send the gNb101′ the value X1211aover a secure session. The gNb101′ can conduct an ECDH key exchange step212and calculate value X2212a, using the received device ephemeral public key Ed103aand the derived server ephemeral private key e1101b. The gNb101′ can calculate the value X3215via ECC point addition over X1211aand X2212a. The gNb101′ can calculate a symmetric ciphering key K1216ausing the value X3215and a KDF216. The gNb101′ can send the mobile device103′ the derived server ephemeral public key E1101in a message206cfrom a step222. Note that some data within ciphertext217bcan be omitted from a message206cin a step222′, where step222′ is depicted inFIG.3aand comprises equivalent steps as a step222inFIG.2a.

The mobile device103′ can receive the message206cfrom a step222′. The mobile device103′, gNb101′, and key server102can conduct a step223, where a step223was depicted and described in connection withFIG.2aabove. The mobile device103′ can send gNb101′ a message210awith ciphertext217d, where ciphertext217dcan include a device identity ID.device103ias plaintext encrypted in the ciphertext217d. The ciphertext217dcan be encrypted with the derived symmetric ciphering key K1216aand a symmetric ciphering algorithm225, where key K1216awas derived by mobile device103′ in a step222′. The identity for the mobile device103ican comprise a subscription permanent identifier (SUPI), and by transmitting the SUPI within a ciphertext217d, the SUPI can remain confidential and not transmitted in the clear through a wireless network. Other possibilities for the use of a step222′ and a step223between a mobile device103′ and gNb101′ exist without departing from the scope of the present disclosure.

FIG.3bis a simplified message flow diagram illustrating an exemplary system with exemplary data sent and received by a client, a server, and a key server, in accordance with exemplary embodiments. System302can include a client103′, a server comprising server101, and a key server102. In exemplary embodiments, client103′ can comprise a client using security steps as described in by transport layer security (TLS) sessions version 1.3 and also subsequent and related versions of IETF RFC standards. Client103′ can also comprise a client using security steps as described in datagram transport layer security (DTLS) RFC 6347 and subsequent versions that incorporate ECDH key exchanges. Although depicted inFIG.3bas a client103′, the client103′ could also comprise a device103, where the device103can conduct the steps of a client103′ at the networking, transport, and application layer of the traditional Open Systems Interconnection (OSI) model.

Client103′ can comprise a computing device that records a network static public key PK.network102a. Note that TLS version 1.3 and DTLS version 1.3 contemplate that the client and a server can use ephemeral ECDH key exchanges (one on the client and one on the server) in order to establish a mutually derived secret shared key for a symmetric ciphering algorithm. The difference between (i) a client103′ (which can comprise a device103supporting TLS or DTLS standards) and (ii) a client for TLS or DTLS standards can be that client103′ can record a network static public key PK.network102a. As depicted inFIG.1c, the network static public key PK.network102acould comprise either (i) a shared key102zacross a plurality of different devices103(or clients103′), or (ii) a unique key102v, where the network static public key PK.network102ais a unique number or string or point for client103′. The key PK.network102acould be received by client103′ in a secure manner before a client103′ conducts a step222with server101. In exemplary embodiments, PK.network102acould be received in the form of a certificate with PK.network102afrom a prior TLS or DTLS session before client103′ begins the TLS or DTLS session depicted inFIG.3b. Or, PK.network102acould be recorded with a set of certificate authority certificates stored with installation of an operating system for device103.

The use of a network static public key PK.network102aby client103′ in a step222to conduct an ECDHE key exchange with server101can have many benefits. The standard handshake as currently proposed for TLS version 1.3 as of June 2018 assumes that a client103′ and a server101have no prior relationship. However, for many instances of communication between a client103′ and a server101, the client103′ may have previously communicated with another server on a network105other than server101. For example, with web browsing a web browser client such as a client103′ will often revisit the same web sites over time, such as a first web site for social networking, a second web site for a search engine, a third web site for news, etc. A TLS or a DTLS session could utilize the fact that the same sites are often re-visited in order to increase security, using the depicted steps of222and223for a client103′, server101, and key server102. Steps222inFIG.3bcan comprise the set of steps222depicted and described in connection withFIG.2a, and steps223inFIG.3bcan also comprise the set of steps223depicted and described in connection withFIG.2a.

Before conducting step222inFIG.3b, a client103′ could receive key PK.network102afrom another server in network105, such as a different web server providing functionality equivalent to server101. PK.network102acould also be stored or recorded by a client103′ along with a set of certificate authority certificates (including root certificates) for an operating system of a device operating the client103′. Or, PK.network102acould be securely received in a previous TLS or DTLS session, such as receiving PK.network102ain a certificate verified by client103′ before client103′ conducts a step222inFIG.3b. The certificate could be verified by client103′ using a certificate authority root certificate, including verification through any intermediate certificate authority certificates. The client103′ could record the network static public key PK.network102ain a table103talong with parameters104aassociated with PK.network102a. In exemplary embodiments, a table103tcould include certificates such as X.509 v3 certificates for the network static public keys PK.network102a, where the certificates include digital signatures from a certificate authority. The key PK.network102acould also be recorded with a URL or domain name (e.g. a server name indication), such that the client103′ would use the key PK.network102awhen establishing a subsequent TLS or DTLS session with server101, where server101uses the recorded URL or domain name. Further, server101could be configured so that any key Ed103areceived from IP network107on an IP address and/or port number used by server101would be forwarded to key server102, where key server102could record and operate with the SK.network102bcorresponding to the public key for PK.network102arecorded by client103′. Server101could also operate such that a URL is associated with a key server102and/or PK.network102a, such that a call or request of the URL could be used to select the key server102and/or PK.network102a.

For a step222, a client103′ can (i) derive a device ephemeral public key Ed103aand private key ed103busing parameters104astored with PK.network102aand (ii) send server101a message203. The message203can include the key Ed103aand the set of cryptographic parameters104aassociated with Ed103a. In some exemplary embodiments client103′ implements TLS or DTLS, and message203can optionally omit a device identity ID.device103i. Server101could operate in a manner such that (i) Ed103ais forwarded to key server102, and (ii) server101derives an ephemeral PKI key pair. Key server102can conduct an ECDHE key exchange as depicted for a step222inFIG.2ausing a step211in order to calculate the secret value X1211a. Key server102can send server101the value X1211a. Server101can use the value X1211a, along with the derivation of a second secret X2212ain order to calculate a symmetric ciphering key K1216a, using the key derivation step213with ECC point addition214over X1211aand X2212a. Thus, by using the embodiment depicted inFIG.3b, a transport layer security session can have security increased, where (a) the ECDHE key exchange contemplated by TLS v1.3 (which would be key exchange212inFIG.2b) can also add (b) the additional key exchange step211aby a key server102. Note that the mutual derivation of symmetric ciphering key K1216aby client103′ and server101can comprise a one-way authentication of server101, since server101can only derive the key K1216aif server101operates in a network105that also records and operates with key SK.network102b.

The server101can send the client103′ the derived server ephemeral public key E1101ain a message206cfrom a step222. Key E1101acould be derived by a step (ii) in the above paragraph. Message206ccould comprise a “Server Hello” according to TLS v1.3 in the document “draft-ietf-tls-tls13-28”. The ciphertext in the Server Hello can be ciphertext217bas depicted inFIG.2a, where the ciphertext217ais encrypted with the mutually derived symmetric ciphering key K1216a. Note that a step222forFIG.3bincreases security for a TLS session, since an active attacker could operate as a “man in the middle” between a real client or “true client” and the server101, where the “man in the middle” could derive its own key Ed103aand substitute that for the real key Ed103afrom the real client or “true client”. Without use of a PK.network102a, a “man in the middle” (deriving and substituting a key Ed103a) could (a) mutually derive a symmetric ciphering key similar to K1216awith server101and then (b) receive and decrypt the ciphertext217b. However, the use of PK.network102acan stop a “man in the middle” attack since a “man in the middle” cannot derive key K1216awithout also recording the SK.network102b, which can remain secret and not available to the “man in the middle”.

The client103′ can receive the message206cfrom a step222from a server101. The client103′, server101, and key server102can conduct a step223, where a step223was depicted and described in connection withFIG.2aabove. The client103′ can derive the same key K1216cusing a step218and the PK.network102a. The client103′ can decrypt ciphertext217busing key K1216a. The client103′ can process the plaintext data, such as recording a certificate for server101(e.g. cert.server101cfromFIG.2a), and verifying a signature101sfrom server101. The client can also read a random number transmitted in the ciphertext217band create a digital signature over the random number. The client can encrypt a ciphertext217dwith data to respond to server101. The ciphertext217dcan be encrypted with the derived symmetric ciphering key K1216band a symmetric ciphering algorithm211a, where key K1216awas derived by client103′ in a step223. Other possibilities exist for the use of a step222and a step223between a client103′ and server101without departing from the scope of the present disclosure.

For the exemplary embodiment depicted inFIG.3bfor support of TLS and DTLS secured data sessions, a message203can comprise a “client hello” message, a message206ccan comprise a “server hello” message, and message210acan comprise a “finished” message from the client103′. For exemplary embodiments, message203as a “client hello” message can omit a device identity103i(such as a permanent identifier for client103′ or device103, but the “client hello” message could include other identifying information for client103′ such as (i) an originating IP address and source port number for message203, (ii) an obfuscated and/or temporary identity such as a random number for a session, and other possibilities exist as well without departing from the scope of the present disclosure.

In addition, embodiments depicted inFIG.3bsolve a significant challenge for resource constrained devices to fully authenticate a certificate cert.server101c. There could be many layers of intermediate certificates between cert.server101cand a certificate authority root certificate stored in device103. Checking for certificate validity for all intermediate certificates and for revocation or OSCP signatures and/or stapling could add many levels of signature verifications. ARM reported a 32 Cortex M4 processor with 32 bits and operating at 84 Mhz requires ˜420 ms for a single ECDSA signature verification (secp521r1) (“Performance of State-of-the-Art Cryptography on ARM-based Microprocessors”, Jul. 21, 2015). There could be 8 or more signatures to be verified for a full certificate chain verification of cert.server101cand related OSCP signatures. A device could conduct the single authenticated key exchange step218in less than 15% of the time and power required for the full, traditional certificate chain verification. Also, there are reduced chances for errors due to unsupported parameters for (x) a single authenticated ECDH key exchange step compared to (y) multiple certificate verifications steps with OSCP verification. Consequently, the communications for a TLS session or DTLS session can remain secured more efficiently using a step222and step223, while recording and using (i) SK.network102bwith network105and (ii) PK.network102awith client103′, compared to traditional TLS or DTLS implementations with multiple layers of certificate authorities through root certificates.

FIG.3cis a simplified message flow diagram illustrating an exemplary system with exemplary data sent and received by an initiator, a responder, and a key server, in accordance with exemplary embodiments. System303can include an initiator103′, a responder101′ and a key server102. Initiator103′ can comprise a computing device103, with the specific additional functionality of an initiator according to the DPP Specification Versions 1.0 from the WiFi Alliance. Responder101′ can comprise a device with (i) electrical components similar or equivalent to a server101depicted inFIG.1babove, and (ii) the specific additional functionality of a responder according to the DPP Specification Version 1.0 of the WiFi Alliance. For example, initiator103′ and responder101′ can communicate via a WiFi network on a LAN between the two devices, which could also comprise the IP network107. Responder101′ can operate in a networked configuration to communicate with key server102via a private network107aor a secure session221as depicted inFIG.2a. In some embodiments, responder101′ can communicate with key server102via an IP network107, where the use of secure session221can create a private network107abetween responder101′ and key server102.

An initiator103′, responder101′ and a key server102can conduct a step222, where a step222is depicted and described in connection withFIG.2aabove. An initiator103′, responder101′ and a key server102can then conduct a step223, where a step223is depicted and described in connection withFIG.2aabove. As depicted inFIG.3c, several PKI keys within a DPP specification version 1.0 can have corresponding keys for a step222and step223. Note that additional steps in addition to those depicted inFIG.3ccan be conducted by an initiator103′ and a responder101′, such as responder101′ deriving PKI keys in a step101xfromFIG.1aand also conducting additional ECDH key exchanges in order to derive a symmetric ciphering key ke in addition to symmetric ciphering key K1216a. In other words, initiator103′ and responder101′ could perform additional ciphering than that depicted for a step222inFIG.2a, but for exemplary embodiments such as that depicted inFIG.3cthe initiator103′ and responder101′ could conduct at least the steps depicted in order to mutually derive a symmetric ciphering key K1216aand use the key to create a ciphertext217bby responder101′ and decrypt the ciphertext217bby initiator103′.

As depicted inFIG.3c, the device ephemeral public key Ed103acan comprise the initiator protocol public key Pi303a. The device ephemeral private key ed103bcan comprise the initiator protocol private key pi303b. The server ephemeral public key E1101acan comprise the responder protocol public key Pr301a. The server ephemeral private key e1101bcan comprise the responder protocol private key pr301b. The network static public key PK.network102acan comprise the responder bootstrap public key302a. The network static private key SK.network102bcan comprise the responder bootstrap private key302b. As described below, other steps fromFIG.2acan be equivalent to those depicted inFIG.3c.

For a message203sent from initiator103′ to responder101′, the message203with the key Pi303acan also include a ciphertext. The message203in a step222can comprise a “DPP Authentication Request” message from the DPP v1.0 standard. Responder101′ can communicate with key server102and receive the value X1211a. Responder101′ can also derive the server ephemeral public key E1101(comprising the responder protocol public key Pr301a) and the server ephemeral private key e1101b(comprising the responder protocol private key pr301b). The Responder101′ can use KDF216to convert X1211ainto a symmetric encryption key (which can be different than key K1216afrom Figures above). Responder101′ can use the symmetric encryption key from X1211ato decrypt the ciphertext with a message203. Responder101′ can then conduct the key exchange step212and step213, along with modified versions of KDF216in order to derive a key ke. Responder101′ can encrypt data with the key ke and send initiator103′ a message206cwith the encrypted data. The message206ccan comprise a “DPP Authentication Response” message from the DPP v1.0 standard. Initiator103′ can then send responder101′ a “DPP Configuration Request” message, which could comprise message210ain a step223as depicted inFIG.2a.

A benefit for the use of a step222and step223for an initiator103′ and a responder101′ is that the responder bootstrap private key br302bcan remain securely recorded in a network105and does not need to be recorded and operated by responder101. In this manner, the responder bootstrap public key Br302acan be freely shared with multiple different initiators103′, including recording the key Br302ain a plurality of initiators103′ in the form of a shared key102zas depicted inFIG.1c. The use of a shared key102zwith multiple different initiators103′ (while keeping SK.network102bor key br302bsecurely recorded in a key server102) simplifies the distribution of key Br302ato multiple different initiators103′.

For exemplary embodiments, the initiators103′ could have a key Br302arecorded during manufacturing or distribution of the computing device operating initiator103′. In other words, a device manufacturer upon device manufacturing with initiator103′ may not know which responder101′ may communicate with initiator103′ during a subsequent DPP session. However, a manufacturer of device with initiator103′ could record a plurality of different keys Br302afor different networks105(similar to different keys PK.network102ain for a table103tFIG.1c), and in this manner initiator103′ can have a higher probability of successfully using a pre-recorded key Br302a(or key PK.network102a) in order to conduct a DPP session without requiring a separate or different additional step of acquiring the key Br302a“out of band”. Thus, the use of the embodiment for an initiator103′ and a responder101′ can simplify the use and deployment of DPP sessions, while simultaneously increasing the securing of the session, since the responder bootstrap private key br302b(in the form of SK.network102b) can remain securely recorded within a network105on a key server102.

Conclusion

Various exemplary embodiments have been described above. Those skilled in the art will understand, however, that changes and modifications may be made to those examples without departing from the scope of the claims.