Posted by KarlP on 3 May, 2012
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!
Posted by KarlP on 17 August, 2011
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-----
-----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
Posted by KarlP on 15 August, 2011
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: