CONSTRAINED KEY EXCHANGE
What EDHOC keeps small, and what it cannot leave out.
A constrained device may have enough cryptography to authenticate a peer and derive fresh keys, but not enough bandwidth or energy for a conventional certificate-heavy handshake. On a lossy radio link, an extra fragment or round trip can dominate the cost of the operation.
EDHOC is a compact authenticated Diffie-Hellman key exchange built with CBOR and COSE. It provides mutual authentication, forward secrecy and identity protection while minimizing encoded messages and reusable implementation code.
Its messages are small because the protocol represents every element deliberately. The security argument is not smaller.
Three messages carry several agreements
The initiator’s first message proposes method and ciphersuite information and contributes an ephemeral public key. The responder selects parameters, contributes its ephemeral key and authenticates its view. The initiator completes authentication in the third message.
From those exchanges, both parties establish identities, ephemeral Diffie-Hellman material, a transcript and exporter secrets. Each field has more than a transport role.
Removing an apparently redundant identifier can change what is negotiated or what the authentication covers.
Transcript hashes accumulate the handshake
EDHOC constructs transcript hashes at successive stages. Authentication data and key derivation depend on these values, binding later messages to the exact earlier exchange.
The transcript includes encoded data, selected parameters and credential-related material according to precise rules. An implementation cannot reconstruct it from semantic objects using a preferred local encoding.
This is a compact instance of the broader rule explored in The transcript is the protocol: both peers must authenticate the same bytes in the same order.
Authentication methods change the cost and assumptions
EDHOC supports authentication with signature keys and with static Diffie-Hellman keys in different initiator and responder combinations.
Signature authentication provides familiar credential models but requires a signature operation and its encoded output. Static Diffie-Hellman authentication can produce smaller messages, but the static key and credential distribution have different compromise properties.
The method number is therefore part of the security profile. Two endpoints that both support EDHOC may not share an acceptable authentication method or credential type.
Credential references save bytes by spending context
A message can carry a compact credential identifier instead of an entire certificate or key. This can reduce the handshake dramatically when both parties already possess or can resolve the credential.
The bytes were not eliminated from the system. They moved into provisioning, a credential repository or an earlier exchange.
The resolver must return one unambiguous credential under the expected trust policy. A short identifier that collides across tenants or key types can bind authentication to the wrong key.
CBOR compactness requires canonical processing
CBOR represents integers, byte strings and structured values efficiently. It can also represent some values in more than one form unless a profile restricts encoding.
Protocol processing must follow EDHOC’s deterministic encoding and validation rules. A parser should reject malformed curve points, lengths, duplicate data and values outside the permitted range before they reach cryptographic operations.
Compactness is useful only when both endpoints agree on the exact compact representation.
Suite negotiation needs downgrade resistance
A constrained implementation may support only one curve, hash and AEAD combination. A more capable peer may offer several suites. The selection process is incorporated into the transcript so that an attacker cannot silently substitute a weaker supported suite.
Error responses can help peers discover a mutually supported option. They can also create fallback logic outside the authenticated exchange.
A deployment should state minimum suites and whether retrying after an error is permitted. Supporting an old suite for compatibility is an operational policy, not an invisible implementation detail.
Identity protection has a direction
EDHOC encrypts or protects identity-related material after ephemeral key establishment. The degree of protection differs by role, method and attacker capability.
An initiator may protect its identity from passive observation and, in relevant methods, from an active peer until the responder authenticates. Network metadata and radio identifiers remain outside EDHOC.
Claims about identity protection should specify whose identity, from whom and at which point in the exchange.
Connection identifiers are small state
EDHOC and OSCORE use compact connection identifiers to distinguish security contexts without carrying full public-key identities in each protected message.
Those identifiers need uniqueness within the scope in which they are interpreted. Reboot, reprovisioning and context rollover can cause collisions if allocation state is not durable or coordinated.
A one-byte identifier is efficient because the rest of the system knows exactly what namespace it belongs to.
OSCORE consumes the exported result
A principal use of EDHOC is establishing an OSCORE Security Context. Exporter-derived material becomes sender and recipient keys, identifiers and common context for protecting application messages.
RFC 9668 can combine the final EDHOC message with the first OSCORE request, reducing latency. This optimization joins two protocol state machines at one packet boundary.
Implementations must ensure that application data is accepted only after the authentication conditions required by both protocols are satisfied.
Loss and duplication are normal
Constrained transports can duplicate or lose messages. A responder may receive the first message again after already producing state for the exchange.
Retry logic needs to distinguish retransmission from a new handshake, preserve the correct ephemeral state and avoid unlimited allocation for unauthenticated initiators. Timeouts should erase secrets without making routine packet loss an attack on availability.
Provisioning remains the first protocol
EDHOC can authenticate a raw public key or certificate only after the application knows how to trust it. Manufacturing, onboarding or an authorization service must establish that relationship.
A compact handshake cannot compensate for a global shared key, an ambiguous key identifier or an unprotected provisioning database.
Small on the wire, precise everywhere
EDHOC shows that a complete authenticated key exchange can fit constrained links without discarding forward secrecy, negotiation or transcript binding.
The efficiency comes from concise encodings, credential references and reuse of CBOR and COSE. Each choice moves complexity into profiles, provisioning and exact state handling.
A compact handshake still has a transcript because every omitted assumption would otherwise return as an interoperability or security failure.
