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)
• Wi-Fi Easy Connect and the Device Provisioning Protocol
• 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.  The download steps are performed by an independent and significantly more resource constrained processor (in an eUICC) compared to the smartphone CPU.  A majority of the time for profile download and activation 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 several minutes or longer, especially with packet retransmissions that are frequent for NB-IoT networks.

Many battery powered IoT devices need to conserve power and minimize connected time and transmissions. Most importantly, according to the Global Risk Institute in 2021, the average estimate from 47 experts is there is a ~50% chance in 15 years that practical quantum computers can break RSA 2048 (with 24 hours of operation).  ECC public keys can be broken in less than 10 years by giving a functional quantum computer several months of compute time.  Consequently, the transmission of long-term, static ECC public keys or certificates should be avoided for new applications/devices planned with an operational 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 very likely have the capability to break the root public key soon after 2030. 

Long-term root certificates will be a primary first target for breaking ECC public keys, and the entire security of systems such as the GSMA embedded SIM depends on the security of root certificates.  Ephemeral public ECC keys for IoT devices should have a reasonable level of security until at least 2035.   Additional protection for many years can be achieved by making static network/server ECC public keys unique for each device (or a relatively small groups of devices such as <1000).  

The highest level of security for the Figure above would use static network and static server public/private keys that are both (i) unique for each device and (ii) public keys are never transmitted unencrypted.  Reasonable security for that system should last until at least 2040 and beyond.  which would cover the operational lifetime of nearly all devices planned for deployment over the next few years.

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.