Authenticated ECDHE Key Exchange With A Key Server


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 ephemeral elliptic curve Diffie Hellman (ECDHE) key exchanges in order to derive a symmetric ciphering key. Prominent examples today include:

  • Transport Layer Security (TLS) version 1.3
  • GSMA embedded SIMs and the ETSI “Smart Secure Platform”
  • Initial authentication within 5G networks (w/ SUCI)
  • GlobalPlatform Open Firmware Loader

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. The ECDHE key exchanges listed above do not include authentication of the nodes within the ECDHE key exchange.  Separate steps using digital signatures and certificates are required for authentication. such as using ECDSA.

An authenticated ECDHE key exchange can be conducted with both forward secrecy and current server authentication status, without requiring the use of server certificates, and OSCP stapling or associated certificate revocation lists. Verifying OSCP stapling through a long chain of certificate issuer certificates to obtain current server authentication status can be (i) quite expensive for an IoT device battery life and (ii) involve significant network overhead compared to the relatively small encrypted dataset the IoT device needs to send to a server.   

As one example, the full procedure for the download of a GSMA embedded SIM profile can require about 1 minute on a smartphone with both (i) high processing capacity and (ii)  high bandwidth availability.  A significant portion of the time is the full verification of  many layers and branches of certificate chains.  For a low-cost "intelligent sensor" connected with an NB-IoT network, the time required for the GSMA profile download could be more than an order of magnitude greater, and many retries required on an NB-IoT network.

Many battery powered IoT devices need to conserve power and minimize connected time and transmissions. Most importantly, quantum computers are predicted to break ECC and RSA within a few years, so the transmission of long-term, static ECC public keys or certificates should be avoided for new applications/devices planned for a lifetime of a decade or longer. One example issue is the GSMA root CI certificate for embedded SIMs is set to expire in 2052, but quantum computers will likely break the public key decades before expiration.

Several solutions have been proposed for an authenticated elliptic curve Diffie-Hellman key exchange using ephemeral keys and static keys. However, these solutions depend on (X) the server/recipient of an ephemeral ECC public key from a device/sender to also (Y) record or operate with the static private ECC key corresponding to the static public key recorded by the sender. This can reduce scalability and security of networks supporting IoT devices, since each server/recipient also needs to record and operate on the static ECC private key corresponding to the static ECC public key recorded by the device/sender.  

In other words, the overall security of systems using previously proposed solutions for authenticated ECDHE key exchanges can be decreased with potentially millions of devices and dozens of servers with a planned lifetime of a decade or longer, where the servers record and operate with server static private ECC keys.  For example, the servers may need to be connected to the public Internet to support the devices, which places greater risks for the server private key.

In addition, a significant drawback for devices deployed for a decade or longer is (a) the risk that server static private key is compromised, or (b) the server recording or having access to the server static private key is no longer authenticated.  Solutions for authenticated ECDHE key exchanges need an efficient method of current server authentication status (e.g. verifying the server public key has not been revoked) without requiring digital signatures, server certificates, and verification through a potentially lengthy certificate chain.  

A device can record at least one network static public key (in addition to the server static public key) to use with the ECDHE key exchange, in order for the network to control the authenticated ECDHE key exchange through a server communicating with the IoT device via the Public Internet. The network can record the corresponding network static private key in a key server that is securely isolated from the server with exposure to the public Internet.  Further, the network static public key and/or server static public key can be unique for each device, further enhancing security and flexibility.  Network and server static public keys can be recorded within devices during initial device configuration before device deployment.

The solution for an authenticated ECDHE key exchange using a key server and illustrated is patent pending.  The patent portfolio includes multiple PCT applications.  The rights to several national stage entries by late 2020 are currently for sale, including BR, CA, CN, KR, MX, MY, JP, RU, TH, ZA.  Multiple countries can be purchased for a discount.  Received International Search Reports from  foreign patent offices confirm patentability.  For more information contact us

Example Calculations with ECC Curve "secp128r1"

Device Ephemeral Private Key - ed


Device Static Private Key - sd


Network Static Public Key - Sn


  • X: 94171534984237685678256585618241417039
  • Y: 203945269464835729838690547089813292056 

Server Static Public Key - Ss


  • X: 319423829544285733939020505180109110187
  • Y: 242179187598040154943588326777101424083

EC Point Addition - Ss + Sn


  • X: 15725052432774382840929761440274832589
  • Y: 217317805140710190286653933543727803288

Private Key Addition - (ed + sd) mod n

  • n:   340282366762482138443322565580356624661
  • (ed + sd) mod n =  199064991727974137923862150658643812563 

Device Shared Secret: (Ss + Sn) * (ed + sd) mod n


  • X: 192457465648897421085529769283600671459
  • Y: 12614498480690967741828130967599964269 

Server Static Private Key - ss


Network Static Private Key - sn


Device Ephemeral Public Key - Ed

  • X: 239356896551017663412726672579682627094
  • Y: 209570745539973929739512070961905802250

Device Static Public key - Sd

  • X: 203473426612520506812902270038827201196
  • Y: 64318327833120582836973711848343026891 

EC Point Addition - Ed + Sd

  • X: 59121922812458579600446751790662160796
  • Y: 304934509235778268978955867170200917057 

Server Point Multiplication - X1 = (Ed + Sd) * ss

  • X: 283470377637256529257925581999478035172
  • Y: 117395441238388206677723127104680679540

Key Server Point Multiplication - X2 = (Ed + Sd) * sn

  • X: 116816232651214939512035210922980929925
  • Y: 26657861758805077188664246487016591812 

Server Shared Secret - X1 + X2 = [ (Ed + Sd) * ss ] + [ (Ed + Sd) * sn ]

  • X: 192457465648897421085529769283600671459
  • Y: 12614498480690967741828130967599964269 

Thus, the Server and the Device Have Mutually Derived the Same Shared Secret