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.