CC3000 Smart Config and AES

One can use AES with the CC3000 and Smart Config - this will prevent arbitrary third parties who do not know the relevant AES key from recovering the passphrase when transmitted by a Smart Config setup application.

AES uses symmetric keys - the same key must be known to the CC3000 enabled device and to the user of the Smart Config setup application.

Smart Config supports 128 bit AES keys. To enter such a key the end user would have to enter a 32 digit hex value, along with the relevant SSID and the passphrase for the relevant network.

Note: the TI Smart Config setup application for Java currently only supports entering 16 characters, each of which may be any valid character value. If we consider the ASCII range from the space character to the tilde, this allows us to encode a little more than 6 bits per character or about 103 bits in total, i.e. noticeably less than 128 bits and considerably less if one excludes characters, such as zero and capital O, that would be hard to distinguish for a user reading the key e.g. from a printed label.

As entering random sequences of characters correctly is not easy for human beings any setup application should probably also require some additional checksum digits so that it can detect if mistakes are made (otherwise if the passphrase is encrypted with an incorrect AES key then the user will get no other feedback beyond the CC3000 enabled device failing to connect to the network).

If an AES key is provided by the end user then the same procedure is used as described before to encode the passphrase except that the passphrase is encrypted into a sequence of bytes using a cipher that implements the AES Electronic Cook Book transformation with no padding, and it is then these bytes that are split into high and low nibble values etc.

Note: AES Electronic Cook Book transformation with no padding would be expressed as "AES/ECB/NoPadding" when creating a cipher in Java - see the "Creating a Cipher Object" in the JCA reference guide and the "Cipher Algorithm Names" section in the JCA standard cipher algorithm names documentation (and the following sections on modes and padding).

Using AES increases complexity for manufacturers, they must encode a unique AES key into each device and determine a way to securely provide this key to the end user, and it reduces the convenience of the whole approach for the end user as they must enter a long AES key as part of the setup process in addition to the SSID and passphrase of the network they are actually interested in.

However without an AES key device manufacturers expose their end users to the risk of broadcasting the passphrase of their network to a malicious third party. Many end users will not be in a position to evaluate this risk properly, incorrectly assuming that any application requesting their network password will handle it in a secure manner.

Delivering AES keys to the end user is non-trivial, e.g. if one manufacturer provides the component with the CC3000 device and sets up the AES key but is not the provider of the completed product then they must provide the key with each component in such a way that the relationship between key and component can be maintained downstream and provided to the end user.

Delivering the keys securely is also a problem. E.g. if the keys were printed on stickers that accompanied the product then it might be possible for an attacker to record the keys before they were delivered to a particular end user. Tamper proof packaging for the key, similar to that used for bank PINs, could at least alert an end user to the fact that the key had been compromised.

Note: even I accept that I'm probably overplaying the secure key delivery issue. A determined attacker, with physical access to devices before they are delivered to the end user, can obviously overcome any issue (even replacing devices with ones they produced themselves). No effort is currently taken to protect against such issues e.g. with wireless routers - the firmware of a wireless router is generally easy to replace and yet no steps are taken by manufacturers to ensure that routers reach end users with unchanged firmware. AES keys printed on simple stickers are probably an acceptable approach.

One could reduce the difficulty of entering an AES key by providing it as a QR code, however QR codes are unpopular with many users and are only appropriate for the smartphone versions of any setup application.

CC3000 enabled devices cannot be used in environments using WPA-Enterprise, i.e. setups where, instead of using a pre-shared key as in home and small office networks, per-user authentication using RADIUS servers is used. As such, devices that do not use an AES key are only putting home and small office environments at risk. This may be a relief to corporate network administrators but is hardly reassuring for everyone else.

Note: in this post I've used the term passphrase, while I've used the term keyphrase in other posts. I did this to to try and distinguish more clearly between the passphrase used to access a network with a given SSID and the AES key used, as described here, to encrypt the passphrase before transmitting it to a CC3000 enabled device.