Question: AES is used successfully all the time. Why shouldn’t we use AES for authentication?
SecureRF: AES is a range of symmetric encryption mechanisms widely available on many devices—for free. You can use AES to authenticate a device, but it typically requires the connection to a database or network and lot of other processing that makes it impractical for just authentication. In short, you use AES by having the same key on two endpoints (Alice and Bob), and then use the keys to encrypt and then decrypt the messages. But the implementation challenge is how did these two endpoints get their keys? And if you have millions of devices, you need to maintain a database of all the keys so you can look up the correct keypair. Maintaining these key databases securely—anywhere in the world the device might appear—and immediately serving up the necessary key is impractical, if not impossible. This is not what AES is intended for.
In contrast, a public key method, like those from SecureRF, enables two entities to meet (that have never connected before) and authenticate (one-way or mutually) without the need to retrieve a key from a database or connect to a network. One of the outputs of this authentication process can be a mutually shared secret (key agreement protocol, KAP) that can then be used to “seed” an AES engine and enable the transfer of encrypted information for that session. So, a KAP is also an enabler and makes securing a wide range of disconnected devices practical. The real elephant in the room—when a vendor chooses AES—is how they are going to securely distribute and manage all those keys. Many users do not realize this problem until it is too late (deployed) because it all looks easy in a demo with a few devices.
Have a technical question for SecureRF? Contact us today