After building, on the previous posts, the Node-Red based backend to support E2EE (End to End Encryption) so we can log data into a central server/database, from our devices securely, without using HTTPS, we need now to build the firmware for the ESP8266 that allows it to call our E2EE backend.
The firmware for the ESP8266 must gather the data that it wants to send, get or generate the current sequence number for the data (to avoid replay attacks), encrypt the data and send it to the backend.
On the backend we are using the Java script library for cryptographic functions Crypto-js, and specifically we are encrypting data with the encryption algorithm AES. So all we need is to encrypt our data with AES on the ESP8266, send it to the Node-Red Crypto-js backend, decrypt it and store it, easy right?
Not quite, let’s see why:
Crypto-js and AES:
We can see that on my Node-Red function code and testing programs I’m using something similar to the following code example:
var CryptoJS = require("crypto-js");
var message = "Message to encrypt";
var AESKey = '2B7E151628AED2A6ABF7158809CF4F3C';
// Encrypt
var ciphertext = CryptoJS.AES.encrypt(message, AESKey );
console.log("Cypher text in Base64: " , ciphertext.toString(CryptoJS.enc.base64) );
// Decrypt
var bytes = CryptoJS.AES.decrypt(ciphertext.toString(), AESKey );
var plaintext = bytes.toString(CryptoJS.enc.Utf8);
console.log("Decrypted message UTF8 decoded: ", plaintext);
Several points regarding the above code need clarification:
The code variable AESKey the way it is used on the above example encrypt and decrypt functions isn’t really a key but a passphrase from where the real key and an initialization vector or salt value is generated (I’m using the names interchangeably, but they are not exactly the same thing except they are public viewable data that must change over time/calls).
The use for the generated key is self explanatory, but the initialization vector (IV) or salt value is used to allow that the encrypted data output to be not the same for the same initial message. While the key is kept constant and secret to both parties, the IV/salt changes between calls, which means that the above code, when run multiple times, will never produce the same output for the same initial message.
Still referring to the above code, the algorithm that generates the key from the passphrase is the PBKDF2 algorithm. More info at Crypto-js documentation. At the end of the encryption the output is a OpenSSL salted format that means that the output begins by the signature id: Salted_, followed by an eight byte salt value, and after the salt, the encrypted data.
So if we want use the API has above on the node-js/crypto-js side, we need to implement on the ESP8266 side both the AES and PBKDF2 algorithms.
I decided not to do that, first because finding a C/C++ implementation of the PBKDF2 algorithm that could be portable and worked on the ESP822 proved difficult, and second the work for porting it to the ESP8266 won’t be needed if I use a KEY/IV directly, and so I decided to use the more standard way of providing an AES key and an initialization vector for encrypting and decrypting data.
In the case of Node-JS and Crypto-JS when using an explicit key and IV the code looks like:
var CryptoJS = require("crypto-js");
var request = require('request');
// The AES encryption/decription key to be used.
var AESKey = '2B7E151628AED2A6ABF7158809CF4F3C';
// The JSON object that we want to encrypt and transmit
var msgObjs = {"data":{"value":300}, "SEQN":145 };
// Convert the JSON object to string
var message = JSON.stringify(msgObjs);
var iv = CryptoJS.enc.Hex.parse('0000000000000000');
var key= CryptoJS.enc.Hex.parse(AESKey);
// Encrypt
var ciphertext = CryptoJS.AES.encrypt(message, key , { iv: iv } );
//console.log("Cypher: ", ciphertext );
console.log("Cypher text: " , ciphertext.toString(CryptoJS.enc.base64) );
console.log(" ");
console.log("=============================================================================");
console.log(" ");
console.log("Let's do a sanity check: Let's decrypt: ");
// Decrypt
var bytes = CryptoJS.AES.decrypt(ciphertext.toString(), key , { iv: iv} );
var plaintext = bytes.toString(CryptoJS.enc.Utf8);
console.log("Decrypted message UTF8 decoded: ", plaintext);
Now, with above code, where the IV is always initialized to the same value, in this case ‘0000000000000000’, we can see when running the above code several times that the output is always the same since the IV is kept constant. Also the encrypted output is now just the raw encrypted data and not the Openssl format.
So to make the above code secure we must randomize the IV value for producing an output that is always different, even from several program runs when encrypting the same source data.
As a final note, if we count the number of HEX characters on the Key string, we find out that they are 16 bytes, which gives a total of 128 key bits. So the above example is using AES128 encryption, and with default Crypto-js block mode and padding algorithms which are CBC (Chain block mode) and pkcs7.
Interfacing Crypto-js and the ESP8266:
Since we are using AES for encrypting data and decrypting data, we need first to have an AES library for the ESP8266. The AES library that I’m using is this one Spaniakos AES library for Arduino and RPi. This library uses AES128, CBC and pkcs7 padding, so it ticks all boxes for compatibility with Crypto-js…
I just added the code from the above library to my Sming project and also added this Base64 library so that I can encode to and from Base64.
The only remaining issue was to securely generate a truly random initialization vector. And while at first I’ve used some available libraries to generate pseudo-random numbers to real random numbers, I’ve found out that the ESP8266 seems to have already a random number generator that is undocumented: Random number generator
So to generate a random IV value is as easy as:
uint8_t getrnd() {
uint8_t really_random = *(volatile uint8_t *)0x3FF20E44;
return really_random;
}
// Generate a random initialization vector
void gen_iv(byte *iv) {
for (int i = 0 ; i < N_BLOCK ; i++ ) {
iv[i]= (byte) getrnd();
}
So our ESP8266 code is as follow:
Global variables declarations:
The N_Block defines the encryption block size, that for AES128 is 16 bytes.
#include "AES.h"
#include "base64.h"
// The AES library object.
AES aes;
// Our AES key. Note that is the same that is used on the Node-Js side but as hex bytes.
byte key[] = { 0x2B, 0x7E, 0x15, 0x16, 0x28, 0xAE, 0xD2, 0xA6, 0xAB, 0xF7, 0x15, 0x88, 0x09, 0xCF, 0x4F, 0x3C };
// The unitialized Initialization vector
byte my_iv[N_BLOCK] = { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
// Our message to encrypt. Static for this example.
String msg = "{\"data\":{\"value\":300}, \"SEQN\":700 , \"msg\":\"IT WORKS!!\" }";
The example function ESP8266 Sming code is:
void testAES128() {
char b64data[200];
byte cipher[1000];
byte iv [N_BLOCK] ;
Serial.println("Let's encrypt:");
aes.set_key( key , sizeof(key)); // Get the globally defined key
gen_iv( my_iv ); // Generate a random IV
// Print the IV
base64_encode( b64data, (char *)my_iv, N_BLOCK);
Serial.println(" IV b64: " + String(b64data));
Serial.println(" Mensagem: " + msg );
int b64len = base64_encode(b64data, (char *)msg.c_str(),msg.length());
Serial.println (" Message in B64: " + String(b64data) );
Serial.println (" The lenght is: " + String(b64len) );
// For sanity check purpose
//base64_decode( decoded , b64data , b64len );
//Serial.println("Decoded: " + String(decoded));
// Encrypt! With AES128, our key and IV, CBC and pkcs7 padding
aes.do_aes_encrypt((byte *)b64data, b64len , cipher, key, 128, my_iv);
Serial.println("Encryption done!");
Serial.println("Cipher size: " + String(aes.get_size()));
base64_encode(b64data, (char *)cipher, aes.get_size() );
Serial.println ("Encrypted data in base64: " + String(b64data) );
Serial.println("Done...");
}
When the above code/function is executed on the ESP8266 it outputs the following:
Let's encrypt:
IV b64: cAFviaDMHejlteGn9/4eQQ==
Mensagem: {"data":{"value":300}, "SEQN":700 , "msg":"IT WORKS!" }
Message in B64: eyJkYXRhIjp7InZhbHVlIjozMDB9LCAiU0VRTiI6NzAwICwgIm1zZyI6IklUIFdPUktTISIgfQ==
The lenght is: 76
Encryption done!
Cipher size: 80
Encrypted data in base64: /1aZRwVaw3jv+ct8HS4pCV5lThvTG70M90ARiyAsIDYMkfJE3w8F3bgxaOKVA0rX4m1Mq50VVN0u9gRw9F2gKE4r2OcY8oECv8bKT80F9pY=
Done...
And now we can feed the above Base64 IV and encrypted data to our decoding program in Node-Js using Crypto-JS:
var CryptoJS = require("crypto-js");
var request = require('request');
var esp8266_msg = '/1aZRwVaw3jv+ct8HS4pCV5lThvTG70M90ARiyAsIDYMkfJE3w8F3bgxaOKVA0rX4m1Mq50VVN0u9gRw9F2gKE4r2OcY8oECv8bKT80F9pY=';
var esp8266_iv = 'cAFviaDMHejlteGn9/4eQQ==';
// The AES encryption/decryption key to be used.
var AESKey = '2B7E151628AED2A6ABF7158809CF4F3C';
var plain_iv = new Buffer( esp8266_iv , 'base64').toString('hex');
var iv = CryptoJS.enc.Hex.parse( plain_iv );
var key= CryptoJS.enc.Hex.parse( AESKey );
console.log("Let's decrypt: ");
// Decrypt
var bytes = CryptoJS.AES.decrypt( esp8266_msg, key , { iv: iv} );
var plaintext = bytes.toString(CryptoJS.enc.Base64);
var decoded_b64msg = new Buffer(plaintext , 'base64').toString('ascii');
var decoded_msg = new Buffer( decoded_b64msg , 'base64').toString('ascii');
console.log("Decrypted message: ", decoded_msg);
and the output is:
Decrypted message: {"data":{"value":300}, "SEQN":700 , "msg":"IT WORKS!" }
So, as the message shows, it WORKS!. AES encryption on the ESP8266 to a Node-JS Crypto-JS based code where decryption occurs.
Final notes:
So all is needed now is to build on the ESP8266 side the message with the encrypted data and the IV, and send through plain HTTP a JSON object to the Node-Red back end.
{
"msg":"/1aZRwVaw3jv+ct8HS4pCV5lThvTG70M90ARiyAsIDYMkfJE3w8F3bgxaOKVA0rX4m1Mq50VVN0u9gRw9F2gKE4r2OcY8oECv8bKT80F9pY=",
"iv":"cAFviaDMHejlteGn9/4eQQ=="
}
On the Node-Red back end the decryption can now be done easily as was shown on the above testing code.
Further reading:
More information also available at: ESP8266 and AES128 for end-to-end encryption and Establishing secure ESP8266 and NodeJs communication by using Diffie-Hellman key exchange and Elliptic Curves
Primal Cortex's Weblog 