WARNING Don’t do this. It does work, but you are limited to sending messages that are smaller than the public key size less padding bytes. The “correct” way is to use the higher level EVP_SealXXXX and EVP_OpenXXXX methods. (which are substantially uglier, but are “the right thing”™ I’ll try and package up some sample code in the neart future
As a follow on from yesterday, where we simply signed the message body being sent to the MQTT server, today we will use public key encryption to secure the message bodies themselves. For an environment where multiple people are connected to the MQTT server, but only one of them is authorized to be reading all the data, this seems a nice way of doing it. We don’t care if any given client is compromised, they only get our public key.
First off, I was less than impressed with the state of the public key encryption/decryption code in python. There’s nothing in the standard library, and PyCrypto doesn’t support reading in standard openssl key files, so I didn’t even bother looking much further. KeyCzar promises to be useful, doing “the right thing” instead of forcing you to know everything about crypto yourself. (I resent having to read the docs closely enough to make sure I chose PKCS_OEAP padding, rather than just PKCS padding for the RSA encryption. I do NOT want to be a crypto guy, and I know that I will never know enough) However, KeyCzar also insists on doing it’s own key management, so I moved on. M2Crypto seems to be the most fully implemented, but, unfortunately, it keeps the terrible/wonderful OpenSSL API. I’m using OpenSSL in the C code, so at least it’s consistent, even if it is a terribly verbose and awkward API.
Other things that I learnt were important, in the C code.
- Remember to call
XXX_free()
on OpenSSL objects that are created. (such as RSA keys fromPEM_read_bio_RSA_PUBKEY
) - Remember that openssl calls to encrypt can only encrypt clear text less than a certain size. (256 bytes in my case)
- Remember that the limit on clear text size does NOT account for padding sizes! RSA_size(key) returns the total size, but with the recommended
RSA_PKCS1_OAEP_PADDING
the overhead is 41 bytes!
The heart of the C encryption side:
int encrypt_message(unsigned char **encrypted, unsigned char *clear, uint32_t clear_len) { RSA *pubkey = rsa_get_public_key(); int rsa_size = RSA_size(pubkey); assert(clear_len < rsa_size - 41); // 41 is the padding size for RSA_PKCS1_OAEP_PADDING ILOG("rsa size = %d\n", rsa_size); *encrypted = malloc(RSA_size(pubkey)); uint32_t encrypted_len = RSA_public_encrypt(clear_len, clear, *encrypted, pubkey, RSA_PKCS1_OAEP_PADDING); RSA_free(pubkey); if (encrypted_len == -1) { fatal("Failed to encrypt data. %s", ERR_error_string(ERR_get_error(), NULL)); } return encrypted_len; } |
rsa_get_public_key()
is some openssl gloop code that you should replace, it provides a hard coded public key I generated yesterday for some tests.
The python decryption code is even simpler:
# This keyfile has had the passphrase removed.... private_key = M2Crypto.RSA.load_key("/home/karlp/karl.test.private.nopf.key") clear_text = private_key.private_decrypt(payload_bytes, M2Crypto.RSA.pkcs1_oaep_padding) log.info("Decrypted message: <%s>", clear_text) |
You can get the code:
Update: The first edition of this post referred to problems with easily getting the binary payload from the MQTT message. This has since been solved, and will be integrated into a future release of mosquitto.