Dealing with HOTP

This time I’m working on the transmission of the firmware into the board. The protocol for doing so has already been established, but there are some issues. The whole procedure for this require some form of authentication for security purposes. This is done through a HMAC-based One-time Password (HOTP), therefore for every process of transmitting the firmware, a new HOTP is generated. The sole purpose of having this is to prevent replay attacks, which is basically a malicious repetition of data transmissions.

In general, part of the generation of an OTP requires an integer counter that increments whenever a transaction that requires it takes place, hence making it only usable for that single transaction. In the case of HOTP, a HMAC Engine generates a hash of that counter using a shared secret key between the server and client. The underlying cryptographic hash function used is usually SHA1, hence the hash output is of length 160 bits or 20 bytes. Since the board addresses memory in 32 bits, we would only need to extract the first 4 bytes from the hash output. Overall, the generation of the HOTP value can be mathematically defined as:

HOTP(K, C) = Truncate(HMAC(K, C)) & 0x7F

where K is the secret key, C is the counter and Truncate is a function that extract the 4 bytes from output. The 0x7F mask is used to set the most significant bit to zero, because there is a possibility of it being interpreted as a signed integer, which is a negative number. This document goes into more detail of the HOTP algorithm.

Going back to the issue, the main problem lies in the fact that both the board and the server needs to have the counter in sync. If the counter on either side goes out of sync, then it is difficult to verify the given HOTP in the board. As outlined in the document, it is recommended to have a look-ahead window from the current value, such that future HOTP values are calculated and finds a match with the received HOTP, as part of the re-synchronization procedure. However, it would be best not having to worry about re-synchronizing the counters. We have thought of some other methods of doing it but it would cause other problems as well, so at the moment I’m just reusing the same old idea.

The implementation of the HOTP has already been done by a previous intern, but now we are changing things a bit. I basically created another REST API endpoint which would be responsible for generating the HOTP and also sending the a bitstream, i.e the firmware, which would be encrypted, along with the HOTP in one the response headers. So far I am able to generate the HOTP value in hexadecimal notation. As for reading of the bitstream file for a project, it is not yet decided how we gonna store it, but I could just create a fake bitstream file for testing purposes.

The next thing I would need to do after that is basically implement the whole firmware transmission procedure, i.e making the necessary HTTP requests to the board. Hopefully life would be kind to me in these times.

Revisiting CRS

On a side note, this week I had the thrill of fixing bugs from my previous project, my beloved CRS. Because the registration is starting soon, Dr Shawn got people to actually play around with with the WooCommerce store and make orders, test the whole flow of the application in other words. Even though I have done my part in testing the application, it is also important to get the users to try out the application as well. You would be surprised what you can find out from it.

One of the bugs I had to deal with was this single ‘&’ character. The registrants could potentially put an ampersand character in fields like the repertoire piece name. This ampersand character has a special meaning in HTML, it is use as the start of a HTML entity, which is used to escape special or reserved characters in HTML. All HTML entities are in the form &….; . The HTML entity for ‘&’ is ‘&”. We use Wt’s XHTML to PDF renderer to render registration slips in PDF, by the way. WooCommerce actually escape this ampersand character for us in the JSON payload of the webhook.

Turns out the problem was actually our choice of a delimiter to distinguish separate repertoire pieces. Earlier we chose ‘;’ as the delimiter. This is problematic if the piece contains the ‘&’ or rather ‘&’ , as the application would split on the last character of the entity! So in the end we decided to change the delimiter to something that is unlikely for someone to key in that accidentally or intentionally in a piece name.

Moral of the story is that users can be unpredictable. They could potentially input whatever they want and please. Lets hope nobody inputs a Unicode character or emojis! 😑😤