[Little Brosers] The User’s Side of The Story

Hello everyone,

This is my first personal post in the logbook, since we finally started working on separate issues in the project. So let me tell you a little bit about what I’ve been working on in the last few days:

Little Brosers App

I have been working on the user’s side of the Little Brosers project, the mobile app. Since I have previous experience in developing Android apps, it was a logical choice for me to explore this aspect of the project and lay the foundations of our future work. I started by looking at the Bluetooth Low Energy capabilities and APIs for android that will allow us to detect and interact with the drops from the smartphone. After looking at the official API and other third-party libraries, I came upon a library developed by Nordic Semiconductor, as well as a PDF document, also written by them, about BLE on Android. Nordic’s library being reliable and simple to use was the final winner.

Using this library I was able to write a very simple android app that was capable of detecting and logging the address of any BLE beacon in range in the foreground (I used an app to turn my iPad into a BLE beacon).

I believe that this is an important first step. Having found a reliable library, the next steps would be the following:

-Implement UUID filters in the scan to detect only the Little Brosers drops.
-Clean the app code to separate as much as possible UI elements from functionality ones.
-Move the detection to the background using Android services.

Note that the last point is tougher than it looks. There are many decisions still to be made regarding the behavior of the app that will affect how we handle this part.

Aside from the mobile app, I will also be working on refining the message structure and the Merkle tree with my teammates, so that we can start developing the core of our project.


Until next week,


[Little Brosers] SoC choice

Here come the end of the third week of ROSE and the Little Brosers project keeps evolving!

For the past week, we have been designing the project based on a approximative idea for the SoC we will use.
We knew we needed a SoC including at least on-chip BLE and some hardware cryptographic blocks like AES and random number generator. The SoC choice should also be conditioned by the chip’s consumption.

Eliminating candidates

First choice was the NRF52840 from Nordic with its “ARM CryptoCell-310” providing a lot of security features that we wouldn’t have to implement in our software. The full description is available here. Unfortunately, this chip is not easily available right now and its consumption could be a problem if placed in a Drop.

We also considered the DA14681 from Dialog Semiconductor with the same kind of features but we’ve been informed that Dialog Semiconductor’s SoCs use to cause problems during implementation and its consumption would also be incompatible with our needs.

The five remaining SoCs

The remaining SoCs we had in mind were the NRF52832 and the NRF52810 from Nordic. Also listed are the QN902X and the MKW31Z from NXP. Finally, one of Cypress Semiconductor’s SoCs could be eligible, the CYW20737 . All of those SoCs have an associated DevKit and SDK.

The main difference between Nordic, NXP and Cypress is the presence of Bluetooth 5 in the Nordic chips. However, even if Bluetooth 5 makes our project ready for the next ~5 years of Bluetooth technology, we won’t take advantage of its higher throughput and longer range because less than 5 main stream smartphones feature Bluetooth 5 for now. Thus, the Little Brosers project will use BLE from Bluetooth 4 standard (even if it includes Nordic chips) in order to be compatible with the most of the smartphones out there.

How to choose the winner ?

The NRF52810 is basically a NRF52832 with less GPIO, PWM, RTC, TIMER and bus protocols. The RAM/flash capacity is also shrunken and NFC, I2S and the low power comparator have been removed. Thus if we go for the NRF52832, we will switch to its little brother only if we realize that the NRF52810 can run our code flawlessly with its reduced memory capacity.

On the other hand, the NXP and Cypress chips are quite similar from each other and for now we can’t decided which one we would pick if we only based our judgement on hardware.

Then comes the manufacturer’s SDK. This is gonna be my main research subject for the next days to determine which SDK will make our development flow easier and therefore, will help us finalize our SoC choice.


Stay tuned !


Antony Lopez

Little-Brosers Week 2: Walking into the unknown

Hello, this is the Little Brosers group. This will be the only post from our group this week as we have all worked collectively on the same subjects until now.


As you may have heard from other groups, the focus of this week was establishing PSSCs (Project Specific Success Criteria), cutting the big project into small digest pieces, and putting deadlines on them. We now have a better view of the road ahead of us, and it was both exciting and a little scary to quantify the amount of work this project will represent for the four of us.


We decide to class our PSSCs into four categories:


  • Algorithmic category, whose aim is to define precisely the protocol followed when a smartphone encounters a drop. The big steps are going to be the “handshake” and authentication, determining which message is missing to each entity, and finally the transfer of said messages.
  • Hardware dependant category, which regroups everything relating the PCB directly: schematics, test of each component, software closely related to hardware (OTA firmware update for example) …
  • Back-end category, which obviously concerns the main server which will act as our certification authority for users, our main tool to synchronize the dates of the drops and prevent a maximum amount of date cheating from users with malicious intents, and finally as a “main drop” connected to the internet to help synchronize messages.
  • App category, which is very important even though it is not the main focus of the project. These PSSCs will help ensure we do not forget to work on the specific aspects of a smartphone app while we are all very busy thinking about the rest.


Here is a link to the wiki of our repo, where you will find the exhaustive and up to date list of our PSSCs, which are obviously going to change in the next few days as we apply the feedback we’ve received after presenting them. You will also find a link to the presentation we gave on friday.


Next week, a few tasks await us. First, precising the theoric aspect of the exchange protocol between the drop and the smartphone. We are going to look for resources about hashing, Merkle trees and symmetrical/asymmetrical cryptography, and try to put on paper a first “pseudo-code” version of our protocol. Second, we are also going to have to put numbers on our needs for the project PCB, to further narrow down the component selection. In our case, we will have to find ways to discriminate the various BLE chips that we have spotted, as well as decide on what external flash we want. And last but not least, as mentioned earlier, we are also going to update the PSSCs to add a few things we have forgotten and correct a few mistakes in the planning.


Thank you all for reading, and see you next week !

The Little Brosers team

Little Brosers, the ones Big Brother won’t watch

Here is the very first post from the “Little Brosers” project !

Quick summary of the project :

  • A set of dead drops (or drops for short), are placed in an area where there is no way to use or setup a regular network. A good example of this scenario are the Paris’s catacombs.
  • A drops is simply a small Bluetooth Low Energy (BLE) receiver/emitter virtually the same size of a coin.
  • The drops are used as a decentralized telecommunication network for smartphones. The network is unique in the way that the drops are not connected together. Instead, smartphones transmit the information between the drops (when they are within the BLE range) in a transparent manner for the user. The users’s phones are the “wires” of our network.
  • Users can send messages (limited length of characters) between them. A group message feature could be added.
  • Messages are authenticated and encrypted.
  • In order to manage users authentication data, we will use a back-end server (connected to the Internet and delivering authentication keys for new users).

Short term objectives are:

  • Clear out the whole signature/encryption/asymmetric key theory for each group member before debating on any cryptographic matter
  • Choose whether or not we need an external flash memory on the drops
  • Settle on features our SoC need to include among:
    • Bluetooth
    • Encryption oriented hardware block
    • Size of on-chip flash storage
    • C API ease of use for Bluetooth and encryption block

Long term objectives are:

  • Define the phone<=>drops protocol
  • Design/choose the file system
  • Choose an encryption method for messages content
  • Choose a strategy to make a ‘git diff’-like  between a phone and a drop. (Merkel tree)
  • Estimate current consumption of SoC (+ external Flash?)
  • Design Drops API for the Backend
  • Backend’s Implementation
  • Design drops’s firmware update process
  • Manage user banishment ( time limited account validity, reset every week/month?)

Starting from now we have 102 days to build this network, and we’re so excited to start ! We can’t stop coming with new applications for the Little Brosers !

Who knows, perhaps even the famous Zerosero 7 will make a request to get a Little Brosers account…