Categories

[Little Brosers] Tree best reasons to start working on our C library

Guess what, I spent less time finding this posts’s title joke than last week. I’m getting good at it !

 

Reason one: No-More-Windows

Let’s just say that designing our PCB using Windows 10 on my MacBook Pro (late 2011) was not the best time effective part of ROSE. More seriously, our PCB’s design is now over. I spent some time this week tweaking last details: adding the VIAs all over the board and designing the antenna to SoC track adapting its impedance to get the most out of our tiny little baby 2.4GHz antenna.

Oh and, I forgot to mention the number one killer feature of this board : There will be the following text engraved in it: “Little Brosers ROSE 2018”. Wow. So fancy. Much professional.

Reason two: Winter is coming, the end of ROSE too

My dear fellows know as much as me how reassuring the countdown of this blog’s welcome page is. Or is it?

Regarding our project, we were building tiny parts of the project until now and some start to interact. (mostly Android and nrf52 bluetooth stack for now)

Our merkle tree implementation and the “diff-like” algorithm written in python by Guillaume are functional but need to be translated to some more optimized C code. This is what I started to do this week and what will fill the next ones.

There is some big issues about how we will allocate the memory for the merkle tree and how we will link it to the messages stored in the external flash. For now, we need to validate the diff-like algorithm in order to test it with the bluetooth stack.Thus, we will simply dynamically allocate the merkle tree. This is still a big chunk of work to do. Of course we will switch to a static allocation later in the project.

Reason tree: Credibility

I just needed three elements to make my joke.

See you next week !

Antony Lopez

[Little Brosers] Exploring the GATT

This week, I have continued my exploration of the SDK and the softdevice. The reason I was not able to register a custom service last week has been found quite quickly: there was a variable in the config file of the SDK/softdevice which held the maximum number of vendor specific GATT service allowed. Running into this problem has made me correctly set up the debugging through RTT, and saved me a lot of headaches for the next obstacle. Once the variable for the maximum number of vendor specific GATT services was correctly set, the softdevice needed more space in memory. Thanks to the debugging messages, we were able to quickly identify the problem and modify the linker script to give more memory to the soft device. Without the precise debugging messages I wonder how much time I would have spent scratching my head trying to explain the crashes of the board.

 

The next thing I did was refactoring the monolithic main.c given as a template by the Nordic SDK to coherent small files. While quite simple in appearance, I have actually spent an entire afternoon doing it, figuring out the correct headers to include from the SDK, and having to change the structure in some cases. Since some definition macro from the SDK declared variables as static, but these variables were needed across multiple files. However this was not wasted time, as it made me more comfortable with the SDK.

 

The remainder of the week has been dedicated to adding characteristics to the GATT service, playing around with read and write rights, and then setting up a timer to transfer the temperature of the CPU automatically through a notify characteristic. This is almost done, and should be finished by tomorrow afternoon.

 

Next week, I want to focus on helping Antony writing the C implementation of our Merkle tree comparison protocol, and I also want to work on the bluetooth side of the Android app, expanding on Chris’s work. I also have some catch-up to do on the server code from Xavier that I have already started.

 

Cheers,

Guillaume

[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] Grounded in a tear drop shape

Ok so… Apart from spending 10 minutes to find a joke for this post’s title, I have well progressed on my Little Brosers tasks.

 

As I said in my previous post, this week as been all about PCBs. First some practice on the PCB design software and those 3 last days were dedicated to the drops’s schematic and PCB.

I’m happy to present you the very first version of our drop’s PCB :

 

To be honest, this is not fully ready yet. On tomorrow class I’ll improve the ground plan exclusion to shape it as a “U” letter.

Also I have to add some fixation holes and two targets for the component placing machine.

The round shape is mostly aesthetic. Since our product is called a “dead drop”, it seemed logical to make round.  It also reduces the size of the PCB since our biggest component is the round shaped battery holder. You can’t see it on the preview image but it is basically the same size than the PCB.

 

Cheers

Antony Lopez

[Little Brosers] Getting to know the nordic SDK

C/Android integration

Since we arrived at a satisfying protocol for the Merkle tree part of the project, it was time to start thinking about its implementation. The first thing I have done this week is make sure we are able to integrate some C code into our Android application. That way, we can write the tree comparison implementation in a C library that we import in the app and we will not lose any time. It was quite straightforward, and despite some missing libraries on my fresh arch install I did not run into serious problems. What is done for now is a simple hello world, where one function acts as the interface using the JNI (Java Native Interface) and call a pure C function defined in a different file which returns a “hello world” c string. The JNI interface function gives this string as a Java string which is then displayed in the MainActivity view. Nothing fancy, but enough to be serene about our ability to integrate C code to our application. However I’m not particularly excited to dive into the JNI syntax for more complex interactions given the difficulty to find concise information about it.

Here is a preview of what it looks like:

JNIEXPORT jstring

JNICALL
Java_com_littlebrosers_drops_littlebrosers_MainActivity_helloWorld(JNIEnv *env, jobject this) {
  char *str = hello();
  return (*env)->NewStringUTF(env, str);
}

Not really sexy. Once that was done, we also had to build a new docker image for our CI since the rose one did not have the NDK (Native Development Kit) installed and it is necessary for compiling C code for Android. Fortunately that was done pretty quickly despite none of us being familiar with docker.

Playing around with the nRF-devkit

After that, I got to play around with the devkit and start to understand the Nordic SDK. Despite being a bit lost at first, I am starting to get the hang of it. Everything bluetooth related is hidden behind Nordic proprietary software called a softdevice, which we can only interact with through an API. That was a bit frustrating at first, but the Nordic tutorials are quite well made, and by going through the examples and learning to read their documentation, I am starting to understand how we are supposed to use the SDK. This is however still a work in progress. I understood how to modify the advertising data, but I am still struggling to add a custom service to the GATT, since the tutorials are made with an older version of the SDK than the one we use. I am currently trying to adapt the nordic services code given in examples to create a custom service, but this is taking time since I do not want to blindly copy anything. This time investment is worth it though, as I will be able to help the other members of the group when they will start to look into it.

That’s what my week has been about. I hope that either tonight or early next week I will be able to register a custom service for the GATT, so that I can continue by adding characteristics to it. Once the BLE technical part is done, we will be able to focus on implementing the Merkle tree comparison protocol in C and interface it with Android on one side, and the Nordic SDK on the other.

Cheers,

Guillaume

[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.

Crypto

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 tree comparison protocol

This week I am going to describe the tree comparison protocol that the drops will be using with the smartphones to determine which message is missing to each device.

 

As mentioned in one of my previous posts, the general idea is that each device has a local stack of operations to keep track of what is the next step. In each element of the stack, there are three informations:

  • The type of the operation: either transmission or reception
  • The type of the transmission (only useful for transmissions)
  • The node of the Merkle tree associated with the operation, which we will call the associated node

 

Here are the three different types of transmissions and their meanings:

  • C, for children: “The hash you sent me is not equal to the one I have, here are the hashes of the children”
  • E, for equal: “The hash you sent me is equal to the one I have, we are stopping here for this subtree”
  • B, for bucket: “The hash you sent me is not equal to the one I have but we are at the end of the subtree (bucket of message) so here are the UUIDs of the messages I have in this bucket”

 

The type of the message will obviously define what the payload contains. After an initialization where one device sends its root hash to the other, we enter the standard behaviour of the protocol which goes as follow:

 

While the device’s stack of operation is not empty, we pop the first operation and look at its type.

 

Transmission:

If the operation is a transmission, we look at the type and build the message payload:

  • C: The hashes of the children of the associated node, add a reception associated with each child to the stack
  • E: Empty payload
  • B: The UUIDs of the messages in the bucket of the associated node

 

Once the payload is formed, the transmission is sent to the other device

 

Reception:

If the operation is a reception, the device waits for the other device to send a message, then looks at its type and payload

  • C: Compares the hashes of the payload with the hashes of the children of the associated node. For each child, if the hash is equal add a transmission of type E associated with the child. If the hash is not equal, add a transmission associated with the child of type C (if the child is not a leaf) or of type B (if the child is a leaf)
  • E: Do nothing
  • B: Compare the UUIDs of the payload with the UUIDs of the bucket of the associated node. Detect which messages the device will have to send, and which messages the device will have to request.

 

This is what the python script simulates and the results have been pretty good so far, so we are pretty happy with that.

 

Next up is something quite different, I am going to catch up on the group’s work on Android and try to make the nrf52832 devkit dialog with the application. I also started to get myself into the Nordic SDK but this has proven to be quite difficult for now since there are a lot of librairies which are often not that great documented. Luckily there are a lot of examples si I am not completely lost.

 

Thank you for reading and see you next week !

Cheers,

Guillaume

[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] Stepping into the PCB’s design

Hello every one!

 

Ok, first things first : yes, my week in Madrid was great. Thanks for asking.

You need to see the Royal Palace if you ever go there, it’s beautiful. Seriously.

Let’s get back to our dear dead drops. I had no chance to publish any post last week but still, there is always something happening in the ROSE’s projects!

 

Updates on PSSC

We began this week with a meeting about PSSCs. To be honest, some of our early PSSC were late on schedule and others had not much time left before its deadline. Thus, the first days of the week were dedicated to put the finished ones in “Wait for validation” state and actually finish the others. We had a code review session as well as an android app test among the team’s member’s phones. The goal was to make sure the ongoing notification (the ones you can’t dismiss by swiping) generated by our app could not be dismissed on any of our phones.

We now wait for the ROSES’s guru’s validation.

 

Lucky me!

Ok, so this week I wanted to start our PCB. The thing is… there is not su much to wire, and that’s great!

 

Indeed, our drops will only contain a battery holder, a flash memory, a JTAG connector, a SoC , a quartz and some passive components. We don’t even need to bother about the battery recharging system because… we don’t need one. Remember! Our goal is to be able to hide our Drops in a hard to reach stash, we don’t care about recharging the battery.

Moreover, our dear Nordic engineers have put into their info center a typical NRF52832 schematic for us. I started from it to design our PCB.

Also, by default I chose the DC/DC power mode for the SoC. We’ll discuss it in our next group meeting, but it is very likely the power mode we will use considering its lower consumption compared to LDO power mode.

About our flash memory, we made the simple choice to take the same than the previous Dead Drops-like project (ROSE 2014). Of course, the idea is not to copy their work but reading theirs posts about this particular flash and their PCB helped me determine how we will wire it for our NRF52. In their logbook posts they also explained the few trubles they had with this flash memory. It’s a work we will not have to waist time on. Thanks’ fellows!

 

I guess that is all for this week.

 

See you next week!

 

Antony Lopez

Https backend

Currently, I’m working on the backend, which will mainly register user by signing their certificates.

Technologies

I work with Flask because everybody in our group know Python and they will be able to understand and review my code !

I chose MongoDB because our db has no relation, it just stores usernames, public keys, and ids.

I work with the cryptography python package, it uses openssl and I found it to be really great (I tried pyOpenSSL, and pycrypto before).

Certificate format

I decided to use x509 certificates because they have already everything we need in them, and they give different serialisation options.

Advancement

My server can already generate and sign a certificate based on the username and the public key given in a http post, but it’s still far from being ready.

I still need to work on:

  • Write the API documentation
  • Write more tests
  • Find the best way to handle CA private key storage
  • Handle User ids
  • Deployment, we will use Heroku for development (of course if there is a real production one day, we will not use it)
  • Get a https certificate (Let’s encrypt !)

We will maybe create a github mirror so everyone will be able to see and try our code !