Cryptography is an essential tool for addressing the privacy and
security issues faced by the Web and the Internet of Things. Sadly,
however, there is a chronic technology transfer failure that causes
important cryptographic techniques to be underutilized.
An example of an underutilized technique is Identity-Based
Cryptography. It is
used for secure
email, although not broadly. But, to my knowledge, it has never
been used to implement secure channel protocols, even though it has
the potential to provide great practical advantages over traditional
public key infrastructure if put to such usage. We pointed this out
in our
white paper on TLS.
Now we have also shown the benefits of identity-based cryptography for
machine-to-machine communications, in
a new paper that we will
present at the Workshop on Security and Privacy in Machine-to-Machine
Communications (M2MSec, San
Francisco, October 29, 2014). Machine-to-machine communications fall
into many different use cases with very different requirements. So,
instead of proposing one particular technique, we propose in the paper
four different protocol design patterns that could be used to
specify a variety of different protocols.
Update (August 4). I should point out that there is a proposal
to use Identity-Based authenticated key exchange in conjunction with
MIKEY (Multimedia Internet KEYing), a key management scheme for SRTP
(Secure Real-Time Transport Protocol), which itself is used to provide
security for audio and video conferencing on the Internet. The
proposed authenticated key exchange protocol is called MIKEY-IBAKE and
is described in RFC
6267. This is an informational RFC rather than a standards-track
RFC, so it’s not clear if the proposed authenticated key exchange
method will be eventually deployed. Interestingly, MIKEY-IBAKE uses
identity-based encryption rather than identity-based key agreement.
This is also what we do in the M2MSec paper, but with a difference.
MIKEY-IBAKE uses identity-based encryption to carry ephemeral Elliptic
Curve Diffie-Hellman parameters, and thus does not reduce the number
of roundtrips. We use identity-based encryption to send a secret from
the initiator to the responder, and we eliminate roundtrips by
simultaneously sending application data protected with encryption and
authentication keys derived from the secret. This gives up replay
protection and forward secrecy for the first message; but replay
protection, as well as forward secrecy in two of the four patterns,
are provided from the second message onward.