Introduction

Bluetooth provides secure connections through pairing and bonding but there are many reasons why the Bluetooth features may not be desirable for your application. For instance, the stack limits you in the number of bonded devices that can be supported. If your design requires you to support more devices (aka clients) then application layer security may be your only choice.

Discussion

ARM specifies a standard implementation for AES encryption called mbedtls. Using mbedtls ensures that your application’s use of the crypto accelerator does not conflict with the stack. This article discusses an implementation of AES128-CBC but can easily be extended to any variation of AES supported by mbedtls. This example uses keys and initialization values of zero, a practical application should use non-zero values for more secure communication. Both the server and client projects in this example are built for the GCC compiler. Two wireless starter kits (WSTK) with radio boards will be required to run this example as described.

Implementation

The example discussed here requires the use of a custom service with two characteristics : one for incoming data and the other for outgoing data. Each data characteristic is 16 bytes since AES128 used here. The incoming data is called cipher_text_in and the outgoing data is called cipher_text_out. Both characteristics have the user type since the user application needs to handle reading and writing.

AES128-CBC requires a 16 byte key, a 16 byte block of data to operate on and a 16 byte initialization vector, both the key and initialization vectors (IV) are set to zero in this example. One IV is required for each characteristic in order for the client and server to remain in sync.

Server

The first step is to initialize the mbedtls module with a call to mbedtls_aes_init().This function requires a pointer to a mbedtls_aes_context struct, a struct of this type is declared extern just main().

Once the initialization is done it is safe to either encrypt or decrypt a block of data. Either operation can be done with a call to the helper function handle_encryption_cbc().This function takes the following parameters : a pointer to the data to be encrypted or decrypted, a pointer to the key, a pointer to the iv and a flag to indicate whether the operation is to encrypt or decrypt.

When the server application receives a request from a remote device to read the cipher_text_out characteristic, the data is encrypted with a call to ciphertext = handle_encryption_cbc(plaintext,key,iv,MBEDTLS_AES_ENCRYPT);

and the resulting encrypted data is sent to the remote system by making a call to gatt_server_send_user_read_response().

Similarly, when a request is received to write the cipher_text_in characteristic, the incoming data is decrypted with a call to handle_encryption_cbc() and the data is printed out.

Client

For demonstration purposes, it is simpler to write a client to run on an EFR32 platform rather than a mobile device. So a sample client is provided.

Upon startup, the client begins listening for a server that advertises our custom service with the UUID 8dcd0dfe-0faf-499a-9993-4010c20db5da. When a device advertising this service is found, a connection is opened. Once the connection is established, the client performs discovery to get the necessary service and characteristic handles.  The client uses a state variable to keep track of its connection and discovery state. This allows the application to perform reads and writes of the secure data characteristics using the gatt_procedure_completed event. This ensures that any previous GATT procedures have completed before attempting another.

The client uses an identical setup of mbedtls and helper function. As with the server, a separate IV is used for each characteristic. Note that if either device resets, it’s IV will be reset to zero and it may become out of sync with the device it connects to. To solve this problem, both IVs are reset to zero as soon as the connection is closed.

Running the Example

The applications are built for an EFR32MG1 but will run on any of the EFR32xG1 SoC or module boards.

1. Unzip “application security client and server.zip” and import the two projects into an existing workspace in SimplicityStudio.
2. Build the server project found in the “application security” folder and download the binary to your target board.
3. Right click on the device in the devices tab and select launch console as shown.
4. Select the serial1 tab. Click in the textbox at the bottom of the console and hit enter to start serial communication.
5. Press reset on the WSTK and you’ll see the following message

Application security server example booted

1. Now build the client project found in the “SecurityClient” folder and download it to a second target board as you did with the server project.
2. Launch the console and hit the reset button as before.
3. The client comes up and displays the following message

Application security client example booted

1. The client begins scanning for devices advertising a service with a known UUID 8dcd0dfe-0faf-499a-9993-4010c20db5da. When a device advertising this service is found, it connects and displays a message such as the following

connecting to remote GATT server with address 00:0B:57:27:B1:07

1. Once a connection is established, the client proceeds through the discovery process to assign handles for the custom service and characteristics. Debug messages that display information about the connection state, crypto operations can enabled by uncommenting the appropriate lines of code.
2. As soon as the writeable characteristic is discovered, the client encrypts the message “First message” as

E66EA45987C01B9C45BABE287E61591 and sends this data to the server. When the readable characteristic is discovered, the client reads this characteristic from the server by calling gecko_cmd_gatt_read_characteristic_value(). The data is received as 55966D11134CB15DBAF7EBC39823F

and decoded as “attack!!”. Note that the encrypted values will change if sent a second time due to the chained nature of the CBC algorithm.

1. It is also possible to connect to the server from a mobile device using the Silabs BlueGecko app. Open the Bluetooth Browser, expand the unknown service and you’ll see there are two characteristics : one with the read and write properties and the other with only the read property. Expand the characteristic with only the read property to see the encrypted data.

Conclusion

Application layer security provides you with more flexibility than the built-in BLE security such as the ability to choose the encryption algorithm but also requires a little more work to implement.

Update: The example code has been updated to support the structure of our Bluetooth SDK v2.7. Please find the new example attached to this article in addition to the v2.4.x example