The Notion of Embedded Chaos

Standard

Encryption has been an important field of science ever since communications became prominent.  Today, all transfers that occur through the internet are encrypted in some way or the other. A similar requirement to encrypt data transfers exists in embedded systems as well. Typically for such applications, encryption is done in software.  The downside of this technique is – it consumes processing time and given that microcontrollers don’t generally have a lot of processing capability, there comes a necessity for hardware based encryption. The current trend of data transfer schemes has no provision for built-in encryption techniques. So if a built-in technique were to be used, these would be its requisites:

• The encryption has to occur with as minimal hardware usage as possible, which will reduce die space during implementation.
• The encryption should be able to secure or abstract the data from external or undesired observers.
• The data should be recovered using least amount of hardware with the highest possible fidelity.

To achieve all these constraints for a hardware based encryption technique, I used the logistic map equation from Chaos theory.

x(n+1) = x(n) * r * [1-x(n)]

If an initial for x(n), between 0 to 1 (other than 0, 0.25, 0.5, 0.75 & 1), is applied to the equation with a suitable coefficient r value as 4, then x(n+1) will be another value between 0 to 1. This x(n+1) will be the next x(n) and the equation iterates. The specialty of this map is that the sequence of x(n) values will look seemingly random. Why? Avoiding the math it suffices to say, It’s chaos.

I used this map and simplified it even further by fixing r=4. If r=4, the map produces chaotic values but in its binary implementation we reduce the need of a multiplier by 1 since multiplying anything by 4 in the binary domain is simple left shifting by two steps and adding zeros. This is similar to decimal multiplication, where multiplying anything by 100 is left shifting by two steps and adding zeros. This results in the following binary chaos map.

The register at the top contains x(n) values. A bit wise negation of the bits and adding a small offset provides a value equivalent to [1-x(n)] and this is multiplied with x(n). The resulting product is to be left shifted by 2 positions for multiplying by 4. But to avoid left shifting delays, it is more optimized to consider bits 13-6 as x(n+1). Thus the binary map produces chaotic codes which are used to encrypt or decrypt data with a mixer/extractor. A simple mixer/extractor is a bit-wise XOR between the chaotic code and the data.

During development, there were a few issues with how the data transfers would require different code cycling depending on simplex or duplex modes.  Irrespective of the transfer modes, the number of nodes to which data is to be transferred, is also important in maintaining sync. This is critical in single master to multiple slaves configurations, as supported by protocols like I2C, SPI etc. For simplicity, I am going to skip the technical details of how these issues are handled. This entire process provides the micro-architecture for embedded chaos.

The analytical performance of the technique was verified using python and Matlab and the results were in favor of the idea – a simplified architecture for hardware based encryption. To verify it practically, two Xilinx Spartan 6 FPGA Development boards are used for encryption and decryption. 4 bit data from 4 switches is encrypted into 8 bits and transferred out where the other FPGA decrypts the 4 bit data and drives 4 LEDs accordingly. An interface board with an 8 bit DAC is used to represent the 8 bit encrypted data in an analog form. This analog signal is seen in the computer based digital oscilloscope.

This was my final year project for my Bachelor’s degree in Electronics & Communication engineering. The technique and architecture developed are a suggested prospect for embedded encryption as built-in solution, due to its least hardware requirement. The correlation of the signals and the analysis shows that the message is sufficiently mixed up with a noise like varying-signal (in the analog version) that cannot be decrypted as long as the initial key is not known, ensuring security.

Working with the 16-bit PIC24F

Standard

I started my microcontroller (uC) journey with the ‘AVR’ and then made it a point to diversify into other awesome uCs. Naturally, the next stop is the famed Microchip’s PIC – Peripheral Interface Controller. Now, when I say PIC it is almost always assumed (in India especially) to be the PIC18F series mostly the PIC18F4570 etc. It so happens that these chips are 8-bit architectures like the AVR (they are classic competitors).

A lot and I mean a lot has been done with this PIC series (18F) to the point that virtually any circuit that can be done has been done and posted on the internet. So, to spice things up a bit I chose to work with the relatively unknown PIC24F series. This series features a 16-bit architecture with superior features (PPS – Peripheral Pin Select is the most remarkable in my opinion) and performance than the 18F. Specifically, I chose the PIC24FJ64GA002 and the best thing for me was, there is not much ready reference circuits or programs available for this microcontroller.

What have I done? I repeated the exact same experiments that I did with AVR. The output is the same but to achieve it was a task, my word, far more difficult to accomplish. And since the output is the same it might be a little boring to see the videos of the hardware implementation, so instead I have posted screen recordings of the simulations (using Proteus).

Since descriptions of the experiments were already written in my AVR article, I would not like to repeat them here. So onto the experiments then.

Simple I/O:

The simulation shows an LED blinking (output) and when the switch is pressed (input) the LED is held on which is truly a simple case of input and output.

As a part of only output programming, here is an LED matrix display that is programmed to display ‘hp07’. The hardware part for this is too straight forward that I stopped with the simulation.

Curiously, Proteus is capable of simulating LCD displays too. As the potentiometer is moved from the minimum to maximum resistance position, the voltage varies from 0-5V and that is read by the microcontroller using the ADC and it is displayed.

PWM:

Proteus can also simulate oscilloscopes that show waveforms. Therefore instead of showing a variation in LED brightness and motor speed (that can barely be seen), the simulation shows it better. You can notice how when ON time (in the waveform) is longer, the motor rotates faster and slow during shorter ON times.

I recently got an instrument called logic analyser that can be used to practically visualize the waveform too. I have a computer interface based one and therefore the screenshot of the waveform:

UART:

Ofcourse, I have to end with the same button presses counting game. When the count button is pressed, a counting interrupt routine is executed with the red LED glowing that counts the number of times the button has been pressed.

And when the transmit button is pressed the data is transmitted through the Universal Asynchronous Receiver Transmitter (the green led glows during this routine). The other microcontroller receives the data and displays it with the help of IC 7447 and a common anode 7 segment display.

The count is re-initialized to zero after every transmission.

And therefore I finished my experiments with PIC. Yea, I did the same experiments as with the AVR microcontrollers. It is easy for me to use a thermistor instead of a potentiometer and post it as a digital thermometer in the ADC experiment. But all that is technically trivial manifestations of the base which is the ADC module. What matters is the program and the base circuit to get it to work and I have done that – therefore mission accomplished!

The videos of the hardware implementation using PIC is on my youtube channel: https://www.youtube.com/user/harshaprabakaran07/videos