Categories

[AmpeROSE] NET API

Hello everyone,

Last week, I talked about the sd API that I had built on top of fatfs API which simplifies some of its calls and adds debug information when debug mode is enabled.

I also showed you the different tests I had made and some of the results.

This week, I have started working on a new API and finished it yesterday. It’s the network API. It uses lwip and is built on top of the netconn API. It aims to simplify some its calls and add debug information like the sd API.

For example, it has the following functions:

  • launchTCPServer
  • launchUDPServer
  • connectTCP

To guarantee the expected behavior, I have developed 4 unit tests and executed them on the Olimex development board.

Have a nice day!

[Little Brosers] Merkle Trees on Android

Hello everyone, this is going to be a long post since I have not posted in a while. I have been postponing in for to long now so let’s go, here is a summary of what I have done in the past weeks.

 

The joy of security libraries in Java/Android

 

What was done up to that point in the Android app in terms of encrypting messages was generating a random RSA key pair on startup and use it to encrypt/decrypt an arbitrary piece of data. While that was good enough at first, we obviously had to store that key pair. That’s when I decided to look at the Android Keystore. This is manipulated just like a Java keystore (a file to store secrets), but the access is provided and controlled the Android OS. The Android Keystore is the easiest and most secure way to store our RSA key pair. Quite quickly I found a way to generate a keypair in the Android Keystore, but for a reason that is still completely obscure to me, I could not decrypt data encrypted using this pair. I tried a lot of other things, but after around a week of tweaking, just when I started to lose hope of using the Android Keystore, I got it working thanks to an obscure post on stack overflow indicating that there was a bug in the AndroidKeystore provider and a workaround one was to be used for the type of RSA encoding we were looking for.

Overall the solution was working, but so much time was lost on this thing. That was also my first experience manipulating security libraries, and I found the documentation really lacking and most of the examples either not working or deprecated. Overall quite a frustrating experience, but I am glad I got it working.

 

Android Unit testing and User management

 

Once that Android Keystore thing was over, I decided to expand Chris’s work on the Message classes to add some User management. The difficulty was to ease the management of multiple networks at the same time in case the project would scale up. Each network is identified by a companyId (company owner of the network) and a networkId. After a lot of back and forth, I settled on a class design where there would be a HashMap of HashMap where companyIds and networkIds would point to a MainUser object. This MainUser represents the owner of the phone, and contains both private and public RSA/ECDSA keys. From this MainUser we can find its ContactUsers on the network indexed by their userIds. Such ContactUsers represent other users of the network, they therefore contain only public RSA/ECDSA keys. The next step was to incorporate it in Chris’s work on Message classes. While it was done I wrote unit tests to ensure the good behavior of all of it, like encrypting then decrypting a message, adding a MainUser to the HashMap, adding a ContactUser to a MainUser, trying to decrypt a message not adressed to us …

 

Merkle tree implementation

 

While I was busy with Android, Antony almost finished the Merkle Tree implementation. I reviewed the code, we improved it a bit, and then I looked at how Criterion works. Criterion is a really nice unit test library for C/C++ code. In less than an afternoon, we integrated its usage to our project structure and our CI. I then spent a few days writing tests for the Merkle Tree structure coherence. Thanks to these tests, we eliminated what we hope are the last few bugs in the Merkle Trees. One issue I encountered was that Antony’s code was written in a way where some hardcoding other than preprocessor maros was necessary if we decided to change the number of children per node on the Merkle Tree. While it was originally ok because it affected a single function in the code itself, it was also needed in every single test. Halfway through, we changed some of the code to reduce the hardcoding to a single macro definition, and made the tests and the rest of the code completely independent of the number of children.

 

Android execution

 

The last thing I have done was getting the Merkle tree code executed on Android. I spent a whole afternoon getting the code to correctly compile, but I have finally done it. It is now possible to generate the merkle tree on Android and add messages to it. The next step, what I am currently working on, is managing storage on the phone for messages. Indeed, the merkle tree code has a construction we named slot_pool, with a linked list to keep track of the messages, and it was designed with the external flash of the board in mind. What I need to do is find a way to associate an “address” in the C code to an “address” in the Android storage. This is still blurry as I am examining the possibilities. Hopefully it will be done and implemented by monday !

 

That is all, thank you for reading, and sorry for the huge gap since the last post, the next one won’t be as long I promise.

[SpiROSE] Led panel assembly and slice format

Led panel assembly

One major issue to design our two PCB was the board to board connection and the led panel position.

In order to have a 80 pixel horizontal resolution with only 40 columns per panel, we need to have the rotation axis between two columns, as the following image shown :

This means two things :

  • The panel axis is not the same as the rotation axis, they are shifted by 1.125mm (half a column), thus the steadiness of the whole must be fixed by adding weight on the rotative base
  • As the panels are meant to be perfectly aligned with one another, the leds and holes has to be symmetrical to the panel axis (not the rotation axis) in order to be face to face with their clone on the other side

For one panel, the connectors are symmetrical to the rotation axis, but when we rotate it by 180°, the connectors don’t align with their clone. This is shown below:

The connector on the rotative base have to be shifted by 2.25mm between the two lines.

The holes on the rotative base also have to be shifted by 1.125mm from the rotation axis to be aligned with the ones on the panel.

Consequences on the framebuffer and slices format

At a given position p, a column on a panel and his clone on the other one display the same voxels. Thus only 40 columns out of 80 are displayed. We have to wait half a turn to reach the position p again, but now the panels have rotated by 180° so the new 40 columns are the ones missing. Therefore we still have our 80 voxels wide resolution.

Hence a slice is displayed in two steps :

  • the even columns first
  • the odd columns half a turn later

This could be handled by the framebuffer module, but would imply to remember at which position we are. In order to remain position agnostic, it is better to let the SBC directly handle this by outputting the slices in an adequate format.

The SBC will cut a slice in two batches, one with the even columns, the other with the odd ones. However, because the panel rotate by 180°, the odd columns need to be reversed to be displayed correctly. All of this is shown in the following figures:

Let’s assume we want to send this slice

At position p we will display the even columns

At position p plus half a turn we will display the odd columns

Thus the SBC will send the slices with the following format

[AmpeROSE] Recalibrating our Architecture

Hello, everyone!

In this post, I’d like to discuss a final significant change that our architecture for AmpeROSE underwent in the end of December.

The calibration problem

As you may recall, a fundamental task for AmpeROSE is to perform “automatic calibration”, controlling in real time the value of its shunt resistance, which is used to convert the current drawn by the device under test (DUT) into a tension that is amplified and measured by an ADC. Each possible value for the shunt corresponds to a range of current values that may be effectively measured with it. Having an inadequate shunt value at a given time can cause the following negative consequences:

  1. If the current is too small for the shunt (there’s a larger available value for the shunt that we should be using), we lose precision.
  2. If the current is too big for the shunt (there’s a smaller available value for the shunt that we should be using), we lose measurements, as the reading will just be stuck at the maximum value for the measurement range corresponding to the current shunt. More importantly, we risk having a brownout on the DUT if the burden voltage becomes large and the situation persists for longer than the DUT’s power supply circuit can handle.

You may consult these two previous posts (1, 2) to review our process for arriving at the automatic calibration scheme we initially based our schematics and PCB design on. Here is a high-level view of it, with the calibration circuit in the center:

In this configuration, hardware comparators are used to generate signals that indicate whenever the amplified shunt voltage has surpassed the upper limit for the current measurement range (VIN>VON), or gone below its lower limit (VIN<VOFF). A third comparator determines whether the burden voltage (voltage on the shunts) has surpassed its maximum allowable value, its output being ALERT. These outputs are fed into a circuit composed of discrete ICS (NAND and NOT gates, SR latches and delay blocks) that implements the calibration logic and generated two outputs (SW1 and SW2) which contror transistor switches which may be used to connect and disconnect resistor in parallel with the shunt, thus changing its value.

In this configuration, it is the microcontoller’s job to read each mesurement from the ADC when it’s ready, through SPI, and sample values of the calibration outputs and of the context bits to associate with the measurement. It also determines the reference voltages for the comparators using its digital to analog converters and controlling a potentiometer.

In the course of the elaboration of our printed circuit board (PCB), this approach for the calibration circuit proved to be problematic, in particular the placing and routing of the different ICs, some of them containing several logic gates that would , not to mention the difficulty of reasoning about the timing of the logic signals. More importantly, the calibration logic would be locked into what is determined by the discrete ICs placed on the PCB, and would be impossible to correct if tests with the finished PCB revealed that corrections would be in order.

In view of these issues, our supervisors encouraged us to consider two alternative approaches that would grant us more flexibility and could be implemented more expediently:

Calibrate using a FPGA

This approach uses a small field-programmable gate array – FPGA (small in terms of package size/pin numbers, and in terms of number of interal logic cells) to implement the calibration logic and generate the SWx outputs. The calibration circuit would be described using a hardware description language such as SystemVerilog, which we have employed often in our embedded systems education, and could be corrected by reprogramming the FPGA through JTAG.

Additionally, we envision using the fpga to read the ADC measurement and the context bits, and prepare and transmit the complete measurement word to the microcontroller though SPI.

Calibrate using the microcontroller

In this approach the outputs of the comparators would be connected to microcontroller pins and would generate fast interrupts, whose service routines would implement the calibration logic and update the shunt control signals.

This design has the advantage of simplifying even more the PCB, and would take advantage of the relatively powerful microcontroller we’re using in our design. On the other hand, performing the calibration does represents a significant burden on microntroller if compared with the circuit with the FPGA, especially because it will also be managing an Ethernet connection.

And the winner is…

Neither! I mean, both! Our PCB will contain a MAX3000A fpga with 44 pins and 64 macrocells, but the components have been placed and routed in such a way that it will be possible to implement either of the designs present above in the PCB, just by reprogramming the microcontroller and the FPGA. The calibration using the FPGA will work essentially as described previously, while for the calibration using the microcontroller, the FPGA will be programmed to simply transmit signals transperantly between the microcontroller and other components in the board.

This strategy will allow us to evaluate the feasibility of both strategies, with the goal of determining which would be more interesting for a more mature version of AmpeROSE. I’m currently working on the SystemVerilog code for the calibration using FPGA, which should then be simulated and tested so we can be confident it’s likely to work when we receive our PCB.

[AmpeROSE] ChibiOS – Sd card

Hello,

In the last two weeks, I was working on the backend, specifically on Sd card. I’m developing code and testing it on the same board that we used during TP: Olimex STM32-E407” before migrating to our real board.
I started by setting up ChibiOS and made some very simple tests (blinking the user-led, etc) to ensure the good control of the board. Then, started the real development.

ChibiOS.17.6.3 integrates fatfs (developed by Chan), an API that offers a very good level of abstraction when communicating with Sd card. It offers a lot of functions, for example f_mount, f_open, f_close, f_write, f_read etc, and it is actually well documented. Before using the Sd card, it must be formatted to fatfs (fat32 is the default one).

Besides the code of Sd card (API Calls, debug info,..), I developed six different tests, each one had a very specific objective. Let’s dive into them…

Test1: Unit test

It does the following:
– create a thread that will wait for the SD card ready state
– the thread will do the following:
* open file: test1.txt in mode rwa(read, write, append)
* write a str defined (5 times)
* write a single character (5 times)
* read a string
* write ROSE using write_sd function (buff)
* read ROSE using read_sd function (buff)
* if an error is detected during write, the thread immediately terminates (ex of errors: disk full, file full, …)
* close the file

It is a very simple unit test, that gave me the control over the Sd card.

Test2: Sd card delay characterizer – write_sd

It consists of a producer/consumer model. A timer (producer) generates data (an msg of 32 bits) and posts it in the consumer (a thread) mailbox (queue, buffer) which fetches each time there is a new message in its mailbox and write it to the Sd card using buffer mode (f_write). In the end of this test, min, max and the average of writing to the Sd card are shown.

Test3: Sd card delay characterizer – write_str_sd

Same as test1, but the goal is to characterize the delay of writing a string.

 

So far, writing each msg alone took a lot of time. Of course, it is not the optimal way to do that but I wanted to see the results to get an idea of the performance then try to optimize. Understand how the Sd card operates in write mode is essential to try to optimize this delay.

In a nutshell, writing to Sd card is read-modify-write of the smallest unit which is the sector (512 bytes most commonly used value). So when initiating a write operation, the Sd card fetches a sector into RAM, modify it with respect to the data that should be written then flush it back to the Sd card (when calling f_flush or when closing the file). So one way to improve the performance is to initiate a write operation with respect to a buffer that has the size of a sector, which brings us to Test4.

Test4: Sd card delay characterizer – write_sd bulk mode

Same as test2 and 3, but instead of writing each message alone, the messages are buffered internally and a write operation is initiated each time 512 bytes were buffered. The improvement was pretty good (the results will be shown at the end of the post).

Test5: Simulation1

AmpeROSE operates in two modes: streaming mode and the standalone mode where the Sd card is actually used to store data. The producer’s frequency is set to 100us and the simulation is run during 10s (default). This test is important because it gives us an idea of the ~minimum mailbox size in order to process all msg and discard nothing. (producer is much faster than the consumer => data might be discarded if there is no place to put it). The result was pretty good, the consumer was able to handle all of the messages without any loss.

Test6: Simulation2

In reality, the max sampling frequency is 100K (10us). This test implements the producer/consumer model with respect to this value using a general purpose timer.

You may be wondering the use of a GPT instead of a virtual timer which is easier and faster in implementation. The is due to the VT limitations. Internally, the VT uses the systick to generate the interruption, the freq of the systick is set to 10K which gives an interruption each 100us. Even when specifying a period of 10us of a VT, internally it is rounded up to the nearest value which is in this case 100us. A possible way to use a VT, in this case, would be to tune the systick variable up, but it is discouraged to do that.

Therefore a GPT is indispensable to implement the real 10us. The result is not good, ~50% of data were lost even by allocating the maximum available size on the Olimex board. In the outputs, you will notice how the percentage of loss decreases when the size of the buffer increases.

And before showing you the results of the different tests, I also added a configuration.h file which gives us the ability to choose between 3 modes (DEBUG, TEST and SHELL modes).
These 3 modes make the development process much easier and by the way, I use SEGGER Real-time coz it is much easier to use by comparing to the shell.

However, in production mode, debugging and testing are not important, in fact, their use will impact the memory space and the overall performance of the system. Therefore, this configuration file permits to disable them in a very practical way.

Tests results

ChibiOS/RTOS initialization

SD connected!
Mounting FS…
FS mounted!
******** Beginning of Tests ********
******** Test1 (unit tests) ********

–> Test1.a: write a string and a character to SD card
File opened
Str successfully written
Chr successfully written
Str successfully written
Chr successfully written
Str successfully written
Chr successfully written
Str successfully written
Chr successfully written
Str successfully written
Chr successfully written
File closed

–> Test1.b: read a string from SD card
File opened
Reading a str from SD card…
Str successfully read
Read the following str: ROSE 2018: AmpeROSE

Reading a str from SD card…
Str successfully read
Read the following str: WROSE 2018: AmpeROSE

Reading a str from SD card…
Str successfully read
Read the following str: WROSE 2018: AmpeROSE

Reading a str from SD card…
Str successfully read
Read the following str: WROSE 2018: AmpeROSE

Reading a str from SD card…
Str successfully read
Read the following str: WROSE 2018: AmpeROSE

File closed

–> Test1.c: write a bunch of bytes to SD card
File opened
Written with success
File closed

–> Test1.d: read a bunch of bytes from SD card
File opened
Read with success
Buff[i (1->4) ]: R O S E
File closed

******* Test2 (Word 32bit) ********

File opened
Please wait…

Statistics about this test
* Buffer size = 3000 (96Kb)
* Generated samples = 2048
* Processed samples = 2048
* Discarded samples = 0
* Remaining samples (in buffer) = 0
* About write operation to SD card:
–> Number of writeSD operation = 2048
==> Min delay (us) = 3000
==> Max delay (us) = 46000
==> Average delay (us) = 4683
==> Total delay (us) = 9591300

File closed

******** Test3 (String) ********

File opened
Please wait…

Statistics about this test
* Processed messages = 2048
* Discarded messages = 0
* About write operation to SD card:
–> Number of writeSD operation = 2048
==> Min delay (us) = 3100
==> Max delay (us) = 54000
==> Average delay (us) = 4619
==> Total delay (us) = 9461300

File closed

******** Test4 (Block 512B) ********

File opened
Please wait…

Statistics about this test
* Buffer size = 3000 (96Kb)
* Generated samples = 2048
* Processed samples = 2048
* Discarded samples = 0
* Remaining samples (in buffer) = 0
* About write operation to SD card:
–> Number of writeSD operation = 16
==> Min delay (us) = 3000
==> Max delay (us) = 21000
==> Average delay (us) = 6175
==> Total delay (us) = 98800

File closed

******** Test5 (Simulation1 – Word) ********

File opened
Please wait…
Time is up, stopping simulation…
File closed

Statistics about this simulation (0min) (3s)
*Total time of execution (0min) (50s)
* Buffer size = 10000 (320Kb)
* Generated samples (by ADC) = 15000
* Processed samples = 10649
* Discarded samples = 4351
* Remaining samples (in buffer) = 0
* About write operation to SD card:
–> Number of writeSD operation = 10649
==> Min delay (us) = 3000
==> Max delay (us) = 94000
==> Average delay (us) = 4619
==> Total delay (us) = 49194100

******** Test6 (Simulation2 – Bulk) ********

File opened
Please wait…
File closed

Statistics about this simulation (0min) (1s)
* Buffer size = 2048 (65Kb)
* Generated samples (by ADC) = 100000
* Processed samples (written) = 27904
* Discarded samples = 72096
* Remaining samples (in buffer) = 0
* About write operation to SD card:
–> Number of writeSD operation = 218
==> Min delay (us) = 3000
==> Max delay (us) = 37000
==> Average delay (us) = 4872
==> Total delay (us) = 1062100

No more tests to run

******** End of Tests ********

ChibiOS/RTOS initialization

SD connected!
Mounting FS…
FS mounted!
******** Beginning of Tests ********
******** Test6 (Simulation2 – Bulk) ********

File opened
Please wait…
File closed

Statistics about this simulation (0min) (1s)
* Buffer size = 4096 (131Kb)
* Generated samples (by ADC) = 100000
* Processed samples (written) = 30208
* Discarded samples = 69792
* Remaining samples (in buffer) = 0
* About write operation to SD card:
–> Number of writeSD operation = 236
==> Min delay (us) = 3000
==> Max delay (us) = 33000
==> Average delay (us) = 4726
==> Total delay (us) = 1115500

No more tests to run

******** End of Tests ********

ChibiOS/RTOS initialization

SD connected!
Mounting FS…
FS mounted!
******** Beginning of Tests ********
******** Test6 (Simulation2 – Bulk) ********

File opened
Please wait…
File closed

Statistics about this simulation (0min) (1s)
* Buffer size = 10000 (320Kb)
* Generated samples (by ADC) = 100000
* Processed samples (written) = 35984
* Discarded samples = 64016
* Remaining samples (in buffer) = 0
* About write operation to SD card:
–> Number of writeSD operation = 282
==> Min delay (us) = 2000
==> Max delay (us) = 39000
==> Average delay (us) = 4779
==> Total delay (us) = 1347700

No more tests to run

******** End of Tests ********

That’s all.

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

[SpiROSE] Last updates on the hardware, happy new year !

It has been time since the last update, I hope you had a good time with the New Year and holidays. Happy new year to everyone and I hope the best for every other ROSE project.

Since the last time I posted, we managed to finish the most important subjects in our work:

  • The last components of our projects have been chosen.
  • The hardware part is (at last) completely done.

MOSFET Driver

First, about the components, we had to choose a mosfet driver so as to have good switching timing. Indeed, we want to overdrive the LEDs so they are visible even if we don’t light them long. So we have to be very precise on the

However, the LEDs are connected to the +5V by their common anode, and to the mass through the LED driver. As we don’t have much place, we have to put the mosfet to the bottom of the LED panel, so it has to connect the LEDs to the +5V. Thus, we have no choice but using P-channel high side mosfet. Difficulties stemmed from this choice.

Actually, P-mosfet are bigger than N-mosfet, and as described by Vincent last time it has been difficult to put them on the PCB. But finding a P-channel high side mosfet driver is even worse. We finally end up with the LTC1693-5 from Linear Technology. It can drive a single channel but we can safely put eight MOSFET on each channel and still meet the timing requirement. It eases the wiring as we light eight columns at a time during a multiplexing step.

Basically, it was the only one MOSFET driver we found within our criteria, so there was no room for choice.

Card-to-card connectors

Then we had to find connectors between our cards. Our first thoughts went to single row 28-pin connectors with a spacing of 1,27mm between pins, with male ones being on the rotative base and female ones on the LEDs panel. However it failed to be routable because it put the flat angle brackets 0.85cm too far from the center, making the LEDs panel bigger than 20cm, too big to go to a pick&place machine. We hereby swapped them with dual-row 1,27mm 28-pin connectors (so 14-pin long) after computing that dual-row 2mm 28-pin connectors weren’t enough and failing to find smaller connectors.

What next ?

Next we will have to reorganize our PSSC for the software, as we noticed before the holidays that most of the time they were either obsolete or overlapped: one critera would ask the work for two and both would be validated at the same time, so there was no use of having them on their previous state. However most of the new plan has been done and accepted by the teacher just before the holidays.

We also have to finish SystemC tests for SPI and framebuffer, implement end-to-end SystemC tests (from SBC output to FPGA output).

We will probably not have the PCB before the end of the project but at least we will be able to show it for the final presentation, so software has to be tested enough so that we can focus on the hardware problems as soon as we receive them.

[Little Brosers] Memory management issues

OK, first, happy new year ! Hope you all had great holida… come on, it’s ROSE’s logbook 😉

So for the last two weeks, I kept working one our lovely merkle tree and all the code it implies.

Interactivity

Indeed, first week was about adding interactivity to the simulation. Thus I added a shell to our simulation program as well as a thread per Device. “Device” is a c++ class wrapping the Little Brosers API which is supposed to emulate a running drop/phone.

Also I added basic C++ TCP server/client to the drops. Allowing them to communicate whenever main’s thread asks them to interact with each other. For now they are only able to ping the other. But I will use this communication channel to implement the diff-like. Indeed, until now, all the code I wrote could be tested without the presence of another Device. All was creating a merkle tree and adding messages to it. No interaction.

In total this interactivity implies 2 threads per Device(one for its “main” thread, another one for the tcp) and one for the main().

Rolling memory

So, while my merkle tree building process was believed to be fully terminated, I noticed yersterday a BIG issue. First some context:

In Guillaume’s Python script, the messages where dynamically allocated whenever it was necessary. Embedded C code does not allow this.

Also, in python, the messages were directly accessible. In our drops, the will be stored in the external flash memory.

Thus, I had to creat a C structure called a “slot pool” :

#define LB_NB_MAX_MSGS 50

typedef struct lb_bucket_slot lb_bucket_slot;
struct lb_bucket_slot {
    lb_bucket_slot *p_previous;
    lb_bucket_slot *p_next;
    message_t *p_msg;
    uint32_t timestamp;
    uint8_t p_hash[MESSAGE_SIGNATURE_SIZE];
};


typedef struct {
    // The + 1 is used to ease the memory management when all slots are full
    lb_bucket_slot slots[LB_NB_MAX_MSGS + 1];
    lb_bucket_slot *begin_busy;
    lb_bucket_slot *begin_free;
    size_t nb_free;
} lb_slot_pool;

As you ca see, a slot_pool is a big array of slots. A slot is a simple structure meant to represent in RAM one particular message stored in the external flash, with a copy of the message’s time stamp and signature for ease-of-use reasons.

So this pool has a limited capacity. Its capacity will eventually be the number of messages we can fit in our external memory. But for now, during simulation, we can choose any size. Here it is 50.

The thing is, what to do when we run out of free slots? Well, we are supposed to free the one referring to the oldest message. This feature was badly implemented by…. me. So i spent the whole day of yesterday re-thinking the management of this pool. And during the process, re-writing the merkle tree build process.

 

Now everything works fine. The slot pool size can be from 1 to +infinite. And whenever a pool of messages is submitted to this merkle tree, it will only keep the newest it can store.

I reviewed the entire code with Guillaume today and we found some edge-cases in the merkle tree build process that wear treated before yesterday (with the bad memory implementation) but not today. However, those cases are easy to solve with the new memory model. In this specific case, I clearly saw that a CI with unitary tests would have noticed me that the merkle tree build process of my new memory management forgot some edge cases that the previous model took care of.So now and more than ever, we realy need to write tests for this whole merkle tree thing. Don’t worry, Guillaume should be on it as I am writing this post.

 

See you next week !

 

Antony Lopez

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

[ZeROSEro7] USB Keyboard detected !

This week, we have finished schematics and PCB. We finally ordered PCB of USB Sniffer, Spy Talk and Stealth Drop devices. I also worked on the USB Keyboard and the SD card.

USB Keyboard

I created a macro to change usbDbgPrintf by rtt_printf. Therefor, all debug functions are usable on the RTT connection.
I listened M. Tardieu advice and I tried to use the USB_FS (OTG1) instead the USB_HS (OTG2). And it’s worked ! The card detects the keyboard and generates interrupt. It’s even possible to print the key pressed on the keyboard thank to the HID USB.
The next step will be sending keyboard descriptors to the computer to be a man in the middle device.

SD card

I started to work on the SD card. I just got back an example from ChibiOS to read and write SD card by the RTT connection.
The software is able to detect the SD card and report information about it but the read command fails.

After Christmas Holiday

I will continue to work on these two issues.