[Little Brosers] The End is Near

Here I am, writing my last post in the logbook. Time passed quickly and right now we’re working around the clock to finish the project before Friday.

As far as I’m concerned, the certificate verification problem that I was stuck on 2 weeks ago was solved a long time ago. The authentication process on the drops is working like a charm, with the drop disconnecting if there is a problem with the user certificate or the challenge response.

On the Android side, I implemented the filters based on the networks we’re active in. Then the results are analysed to tell if we should connect to a drop or not. In addition to that, I have laid out the entire connection process on drop discovery, with stubs for the yet unwritten processes. I’m currently working on finishing the authentication process on the Android side. Challenging a drop and verifying its response, as well as responding to its challenge are working perfectly well. However, given that the user certificate is not yet ready, I’m putting that part on hold for now, and working on communicating with the server to obtain the user certificate on signup.

During last week, while implementing the authentication on Android, I realized that we couldn’t write more than 20 bytes (the default MTU size on the drop) to a characteristic, which was problematic given that we have much larger characteristics, like the challenge/response and the certificate. I solved this problem by increasing the MTU size on the drop to 214 and implementing long write operations, which allow Android to break the data into multiple packets that are sent sequentially to the drop. Upon reception the drop’s BLE stack asks for a memory block that will hold the temporary data, and then writes the whole data in the characteristic.

I hope you enjoyed reading my blog posts as much as  I enjoyed writing them, but now, I have to get back to work.

[Little Brosers] That Key

This is an update on the authentication service I’m still working on. Yesterday I managed to parse the user certificate in DER format and extract interesting fields, such as the validity dates, username, public key and signature. However, in trying to bring it together with the rest of the service, in other words using the parsed public key to verify the challenge response, I ran into a bit of a problem. Upon further investigation (and to spare you the unnecessary details) I realized that if I try to compute the public key from a private one with the nRF crypto library, the output is different than the public key obtained with OpenSSL.

I spent all afternoon working on this so it’s a fresh issue right now. I read somewhere that endianness may be causing this, but my first tests didn’t show any promise there. If you have any ideas or suggestions I’m all ears!

Other than that, I still have to include the server’s public key in the code to test the certificate’s signature. I also have to transform the dates that I parsed into a more convenient format that we can use to compare to the date provided in the time certificate (which we still haven’t touched yet).

[Little Brosers] Authentication

I want to start this logbook entry by wishing everyone a merry Christmas and happy holidays!

Now let me give you an update on the authentication service. Last week I told you that I started working on it, and that the service, as well as its characteristics, were up and running. Since that time I have implemented and tested the challenge generation, response and verification on the devkit. But before doing that, I wrote a few wrapper functions for the existing crypto and hashing functions in the SDK just to make our lives a little easier. Now let’s talk about the challenge/response mechanism.

The idea is to use a random number generator for the challenge. That number is placed in the corresponding characteristic that’s available as read-only to the connected client. The client then has to read that number, sign it and write the signature in the corresponding write-only characteristic. The drop then read that signature and verifies the signature based on the public key given in the user certificate.
And vice versa, when the client sends a challenge to the drop, it writes a randomly generated number in the proper characteristics that the drop will read and sign. The signature is placed in a read-only characteristic that the client will read, and verify to make sure the self proclaimed drop is indeed a real one.

Which leaves me with the last 2 bricks of this task, processing the user and time certificates. Our backend server currently generates a x509 PEM certificate per user, and the drop has to parse and verify the contents and validity of the certificate to allow the user to exchange messages with it. I’m just starting to look at this type of certificate, its format and the data it can hold. For the moment I haven’t done a lot of research, so I’m still not sure if I’ll have to do the parsing manually or use an existing library for that. Either way, I should get back to work…

[Little Brosers] Who Are You?

Last week I mentioned that I will start working on the authentication part, however, there was a PSSC that needed to be closed fast so I worked on it for the most of the week. It was basically about making the drop able to read a message from a sequence of bytes and verify its signature. This was simple considering I did exactly the same thing in Java before but in a more complex way.

Besides that, I started working on the authentication service. I created a new GATT service and added characteristics associated with the data that will be exchanged. The drop will always request the user’s time certificate, and the certificate with his public key, both signed by our server. After that, it’s a challenge-response mechanism; the user sends a random number to the drop which the latter has to sign (to make sure it’s not a rogue drop), and vice-versa to authenticate the user. After this stage is passed, both parties can start the Merkle tree comparison and the message exchange.

For the moment, the service is up and running, and the characteristics available with the proper read/write permissions. The next step would be to work on the backend of this service, that is the challenge creation, response, and verification as well as the verification of the user and time certificates.

[Little Brosers] Messages Done

Last week I was in the middle of finishing the message structure, parsing and encoding, on the Android side in Java. I’m pleased to announce that the mobile app can now properly encrypt and sign a clear text message and transform it into an array of bytes that will be sent over BLE, as well as parse that raw message and transform it back into the clear text message. This means that for the moment my work in the Android part is over.

Besides that, I started working with the Nordic development kit, by trying to understand the examples provided, and how everything works. During that time I also managed to implement our advertising protocol on the devkits, which means that now, they are advertising themselves are proper drops from the Little Brosers network! In a nutshell, I implement the protocol described in one of my previous posts [Little Brosers] Being Heard.

Next Steps

The next step for me would be working on the authentication aspect of our protocol (which will be slightly modified) using a GATT service.

[Little Brosers] Messages

This week I’ve worked extensively on the generation and parsing of messages in the mobile app. While I was planning on getting started with BLE on the devkit, I had to take care of this PSSC first.

Message Structure

The idea is to define a structure for the messages that will be handled in the app, as well as the interface with the raw messages that will be exchanged over BLE. In order to do that I implemented this kind of structure:

Raw message represents a message as a sequence of bytes that are exchanged over BLE. GenericMessage is the Java representation of any message object that has a header, payload and signature. It takes care of going to and from a raw message. After a message is parsed and transformed into a GenericMessage, its type is checked and then an object with the corresponding message type is created and handled by the app. For the moment we only have one type of messages, which is EncryptedTextMessage.

We put time and effort into this one in order to make it as simple as possible to add other message types in the future without having to rewrite the app’s code. A more detailed description is available in our wiki Java message structure.


Another big aspect of generating messages is taking care of the cryptographic aspects, which are signature and encryption. I’m working closely with one of my teammates who’s handling the back-end side of our system (server and certificate authority) in order to be able to generate properly encrypted and signed messages as soon as possible.

Little Brosers ID

We also chose our 4-byte Little Brosers ID that will help us identify BLE advertising messages that come from our Drops. I won’t reveal what it is but I’ll only say that it has something to do with initials 😉


For Next Week

I plan on having working messages before the end of the week. I’m also hoping to start working on the devkit to implement our protocol over BLE (as described in a previous post).

[Little Brosers] The Delights of Working with Android

Hello everyone,

Last week I resumed working fully on the Android app, the app on which I’ve been working On/Off for about 3 weeks. My major sticking point was moving the scanning to a foreground service, which is a service that the user is aware of, and that keeps running after the app is swiped from the recent apps list (that is as long as the system has enough memory for its other tasks). The problem was that on my device, the Huawei P9, the service was getting killed the moment I swiped the app from the recent apps list. I tried everything I possibly could, until a teammate of mine tried the app on his phone, and it worked like a charm. What a delight it is to work with Android, where every device acts in its own special way. After a long search I was able to find the setting that made my app work on my Huawei.


So right now the app scans for BLE devices in a separate service, in a separate process, and when it finds one it sends a notification with the BLE device’s address as a proof of concept at the moment.


BLE scan screenshot


With that out of the way, we can now focus on refining the scanning, while implementing our filters to wake up the app only when a Little Brosers drop is detected. The global protocol is explained in one of my previous posts.
For now, with the help of the dev kits, we will bring the app closer to reality and make it establish a conversation with (what will act as) a real drop.

[Little Brosers] Starting The Conversation

Last week we saw the hierarchy of our network, as well as the initial connection stage. Since then I’ve continued to work on the communication protocol over BLE between the drops and the mobile app.


Our authentication protocol is there to guarantee two things: First, that the smartphone belongs to the Little Brosers network (and to the specific network in particular), and second that the drop is indeed a real drop of the network. These verifications will be done using a challenge-response type of protocol.

However, over BLE, the most commonly used protocol is Generic Attribute Profile (GATT), which defines services that group characteristics which essentially are value you can read or write over Bluetooth.

The GATT server will be running on the drop after the connection has been initiated by the phone. After that, the authentication service will be activated, and it will be after passing this stage that the rest of the services will become available. To implement this double authentication, I thought about adding four characteristics to the server:

  • User_challenge (read)
  • User_response (write)
  • Drop_challenge (write)
  • Drop_response (read)

Note that the read/write permissions are seen from the smartphone’s side of the interaction.

So after all each party gives a challenge to the other, and waits for their response. If the response is incorrect the connection is terminated. However, if both pass this phase, then they can proceed to the next stage, which could be more verification steps or simply the start of the message exchange.

[Little Brosers] Narrowing the components list and pushing my first commit !

SoC final choice

After more digging into SDK features, we finally chose the NRF52832 from Nordic as our SoC thanks to Nordic’s great SDK.

Why this choice ? I’m glad you asked!

Comparing NXP, Cypress and Nordic SDKs, I came to the conclusion that our development process would be simplified the most using Nordic’s SDK. Not only the C libraries from Nordic such as the nRF5 SDK v14.1.0 are impressively well documented but we will also be helped by the Nordic Android BLE SDK and user guide for the mobile app we plan to develop.

Other tools may be considered. For example, Nordic provide the Power Profiler Kit allowing developers to estimate the current consumption of the SoC during our code execution from 1µA to 70mA with a resolution of 0.2µA.

Also, Nordic’s SoC come with OTA firmware update feature. Allowing us to easily setup the firmware update process though BLE.

Choosing the Flash memory

We had less specific needs for the flash memory.

To estimate the needed size, I used the following values:

  • A message with payload +  Little Brosers’s overhead should take less than 400 bytes
  • A drop should be able to store around 9000 messages
  • A worst case scenario 4-ary Merkle tree with this configuration should have a size of 300kB with 128 bits long hashs
  • The total of those estimation gave us a size of around 4MB

Of course those estimations are not precise but 9000 messages is quite a big number and we’ll allow us to store less messages on a drop if needed.

I also knew that a easy to solder package like SOIC-8 would be way more convenient during the soldering process of our PCBs.

In the end I had 5 flash models packaged in a SOIC-8 with similar features and I selected one of average price, well balanced set of feature and allowing several power modes to adapt its consumption. This is the AT45DB321E from Adesto Technologies.

Pushing my first commit

Indeed, for the drops firmware we plan to separate the C source code supposed to be used in the drops and the C++ source code only executed one our PCs to perform quick simulations. This structure should allow us to develop the hardware independent C code for the drops and test it using C++ ease of use. Those simulations will allow us to perform Merkle tree merges without the whole BLE communication process. We will emulate it with C++ objects.

So, i spoke about my first commit… and what a commit !

Indeed, we decided to start from a Nordic’s SDK’s example four our Makefile structure. Thus, I had to put the whole Nordic SDK in the repository (~120MB).

In the following weeks, I’ll work on editing the Nordic’s Makefile to include our C++ simulation environnement.

Eventually, we would like to have a Makefile from which we could run the following kind of targets:

  • make sim : build a x86 binary including hardware independent C code and the C++ simulation code
  • make devkit : build an ARM binary for the NRF52 DevKit including hardware independent C code, SDK and DevKit specific code
  • make firmware : build an ARM binary for the drops including hardware independent C code, BLE code, SDK and Drops specific code
  • make clean : well… clean the project
  • make flashdv : flash the DevKit with its dedicated binary
  • make flashd : flash a Drop with its dedicated binary

See you next week !!

Antony Lopez

[Little Brosers] Being Heard


If you’ve read my last post, you’re probably expecting me to have finished the Bluetooth discovery part of the mobile app. However, sometimes in order to go forward, we have to take a different route, which is why today, we are going to delve further into BLE advertising. But before we do that, let’s take a look at the way we imagined the hierarchy of Little Brosers:



  • Company A
  • Company C
    • Network A
    • Network N
      • Drop 1
      • Drop 2
      • Drop 3

Let’s explain more what each level represents:

  • Company represents the company or the entity that is able to create and manage drop networks. We’re still not sure if we want to add this level or not.
  • Network represents a network of drops within a company.
  • Drop represents the individual drops inside a network.

BLE Advertising


Now that that’s out of the way, we can take a look at the BLE advertising packet, more specifically the connectable undirected advertising. It’s made out of a normal BLE packet, where the payload contains 2 sections, AdvA, a 6-byte device address, and AdvData, the actual data being advertised, which can take from 0 to 31 bytes. Our focus is on the AdvData section, which in itself can contain multiple advertising data structures that can offer different types of info. We however, will target a specific type called “Manufacturer Specific Data”. 

Let’s not forget that when the drop is not connected to a device, it will be transmitting this advertising packet at a constant interval, and since this is an essential part of the process, it would be a good idea to use it to announce as much information as possible so that the smartphone can tell from the advertising alone if it needs to connect to this drop or not.

Back to manufacturer specific data, the format is the following:

  • Company ID (2 bytes)
  • Manufacturer data

The company ID is an assigned number by the Bluetooth SIG. This will probably force us to use a specific value that we have no control over in order to stay compliant with the specification. However, the manufacturer data part is where will put the info we need.

  • Little Brosers ID (4 bytes)
  • Company ID (2 bytes)
  • Network ID (2 bytes)
  • Drop ID (2 bytes)
  • Additional info to prevent unneeded connections

Company, network and drop ID are IDs for the elements within the hierarchy detailed above. Little Brosers ID is a magic number that will define to identify the drops as part of the Little Brosers project. The scan results filter of the mobile app will act on these fields to determine if the detected BLE advertisements are of interest or not.

Our Own UUIDs


In Bluetooth, services are identified by a Universally Unique IDentifier (UUID). Custom UUIDs which are 128-bit long are used for custom services not registered with the Bluetooth SIG. So in order to follow the same method used for the registered services, we decided to give a 16-bit ID to our services, while changing of course the base UUID so that we do not use the default Bluetooth assigned numbers. Our custom base UUID will contain the following elements:

  • Little Brosers ID
  • Company ID
  • Network ID

I’m not sure if we will include the drop ID as well. At this point it doesn’t seem to be useful here.