Tag Archives: c

MRF24J40 driver for STM32

A while ago I put together a C driver for the MRF24J40 802.15.4 modules from microchip. I had been using them as a cheap alternative to xbees in some AVR projects. As I’ve been moving on to STM32 parts for hobby projects, (more power, cheaper) I started off porting my driver code from AVR over to cortex m3.

This has been quite an experience. The arm toolchain experience, and particularly the libc support and general documentation is completely different to, say, avr-libc (AVR-libc is a great project, reallly solid)

However, with lots of learning, and lots of mistakes, I’ve got it all working. It’s a first cut, but the basic features are there. There’s no magic for DMA, and you have to do a lot of the pin setup yourself, but this is Cortex M3, there’s so many pins you could be using for this! I’ve tried to reduce the required function calls as much as possible, but there’s still room for improvement.

    // Required by the user code
    extern void mrf_select(void);  // Chip select, if necessary
    extern void mrf_deselect(void);  // chip deselect, if necessary
    extern uint8_t spi_tx(uint8_t cData);
    extern void _delay_ms(int);  // only used at init time.

This still needs to move to a clear sub project, currently it’s a separate code base to the AVR code.

Get the code now!

More to come, as it gets tidied up and put into use!

OpenSSL PEM_read_RSA_PUBKEY vs PEM_read_RSAPublicKey

File this in the “Everybody hates OpenSSL’s API” category. From the expansive documentation:

The RSAPublicKey functions process an RSA public key using an RSA structure. The public key is encoded using a PKCS#1 RSAPublicKey structure.

The RSA_PUBKEY functions also process an RSA public key using an RSA structure. However the public key is encoded using a SubjectPublicKeyInfo structure and an error occurs if the public key is not RSA.

Seeing as I’m in the “PEM” functions, so at least in theory, I’m using methods for processing files that look like this:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxKMFS0eoDxn6YltlCM4P
uIHK1bp3+7Lt0aWZ9rimjd4uvx49ZYT1DKrUZi96rUkzdJuCqtYbFtUVAy0V5AtZ
EtQGRoZBN5JQ9u80I8NNS4jhtHZU2i6CY9Aeb6KHY790ceD+lMCbXCgrtl1yPUVE
s8pFwEwO2Vqjim2pO0iVsAzUJAyppjn/7FjxyqOHZHL+OPi7vNule1V9OdVrb9m3
mHVy3u9LWdA+3Ch/YJe8FgenRncQEVrDbA/0wHlRE5fH+nQ9OwPTDYP6A6pphAbk
ZUhc9VjIDKrTCQP2o4RDLz0OKyBs5xZc7vjGXpHG+kL3OVpHxpSrK9EVGIX65ofN
9QIDAQAB
-----END PUBLIC KEY-----

I’ve got no idea where the PKCS#1 vs SubjectPublicKeyInfo comes into it when I’m just trying to load that file. Regardless, the only one that works is PEM_read_RSA_PUBKEY()

HMAC signing MQTT messages, with C and python

MQTT as a protocol is pretty light on security. There’s a username/password fields, but they are clear text. Mosquitto, the implementation that we’re using right now supports using these fields to limit read/write access to given topics, but it feels a bit hard to manage. We would have to have a file with each topic in use, and multiple lines for each and every user in our system. (We have multiple clients over the internet, and we don’t want to let them see each others messages)

Instead, we’re going to have clients use our public key to encrypt their messages, and then use a shared key per client to sign the messages. This means that we can be sure that the message was not tampered with, that only someone with knowledge of a certain client’s key can pretend to be that client, and that no-one without our private key can actually read the messages. Our listener will first verify the signatures on each message. If a messages was received on topic “clientAAA” but fails to verify with the shared secret key of clientAAA, then we drop the message before even attempting to decrypt. If they match, we can decrypt, and process the contents.

I’ve put together a basic demo of the HMAC signing part, with a message publisher in C, and a message verifier/parser in python. Hopefully it will be useful to someone.
The code is available: