Light Weight Steganography on RISC Platform-Implementation and Analysis

MATERIALS AND METHODS

This work suggests a fiction block based on fixed embedding procedure on grey scale images, where, the secret data will be encrypted before the embedding process. In this sequential embedding approach, the use of different keys for the encryption of secret bytes to be embedded in each block makes the same secret to appear differently at every point of embedding, even, when same data gets embedded in multiple places. The user can decide on the number of chunks to be made in every cover image. Also the number of Cover Bytes (CB) in each block for embedding is selectable by the user. In the beginning, the user has to select the Block Size (BS), a 10 bit integer number as given in Eq. 1.

(1)

The lower 8 bits are extracted from the selected BS value of the ith block and taken as the Base Key (BK_i = BS_i and 0×FF) for encrypting the data for the ith block. Since, we go for fixed ‘K’ bit LSB embedding on each pixel, the number of secret data bytes to be encrypted using the selected key can be given as j = (BS-HB)/4, when, K = 2 and Header Bytes, HB = 5. A 3-bit LFSR circuit shown in Fig. 1, is used to transposition each bit of BK_i to obtain a Bit Shuffled Key (BSK_i). The 3-bit LFSR with an EX-NOR gate in its feedback path generates pseudo random numbers in the range of 0 to 6 as given in Table 1. As the LFSR circuit with a feedback path through EX-OR gate by no means output all zeros, a feedback set by an EX-NOR gate on no account produce all ones. Therefore, prior to the start of embedding the data in every block, the LFSR is made to run 7 times and the value 7 is inserted at the end to complete a cycle.

Table 1:	Output of 3-bit LFSR with EX-NOR feedback

Fig. 1:	LFSR (3-bit) with EX-NOR feed back

The pseudo random output of the LFSR in one cycle, PS_i for the respective seed value Sd_i dictates the sequence by which the bit positions of the 8-bit key, are to be rearranged to get a Bit Shuffled Key (BSK_i) that scrambles the data to be embedded in the ith cover block. The LFSR seed value for the ith block is agreed as Sd_i = Bk_i mod 8. The simple symmetric encryption for each secret byte comprises of a transposition mechanism followed by an Ex-or operation given by the Eq. 2 and 3, respectively.

(2)

(3)

In this approach, the selected BS value for each block is embedded in the five foregoing cover bytes of the respective block, which are called Header Bytes (HB) and the remaining cover bytes of the relevant block will get embedded with encrypted secret data block, to obtain the stego block, SB (BS_i). Block size of any selected block is given by Eq. 4.

(4)

where, RSB is the Remaining Secret Bytes to be embedded.

In practical cases, the final block that gets the secret data embedded is called the residual block. It may not follow the size given by Eq. 1 due to the fact that the size of the cover image will usually be more than the size of secret data. Once the left over secret data bytes got embedded, the next cover block is embedded with 10 zeros in the place of header bytes called as Concluding Bits (CCB = 00 00 00 00 00) indicating the closing stage of secret data embedding.

The retrieval process starts with the extraction of block size from the Header bytes in the first block of the stego image. The extracted BS value is used to reconstruct the Base Key and 3-bit LFSR seed, SD_i used at the encryption side. The output sequence of LFSR and Bit Shuffled Key, BSK_i to decrypt the secret data bytes in the encrypted form from every ith stego block is conceded in a way similar to the encryption process. This extraction and decryption are sustained until we attain the concluding bytes in the header. Finally, the retrieved secret image, (RD_x×RD_y) is reconstructed using the decrypted data. The overview of the entire process is depicted in Fig. 2.

Hardware implementation: The algorithm focuses on grey scale images that can be fit in to the existing on-chip SRAM of 32 KB in the embedded processor LPC 2378 chosen for hardware implementation.

Fig. 2:	Block diagram of stego system

The real cover image, stego cover, secret image in its actual plus encrypted form and the retrieved secret image as well are stored in local on-chip SRAM of 32KB. The algorithm was developed as an embedded software using the Embedded-C language. The embedded code was compiled with ARMCC compiler of KEIL MDK version 4.7 and IAR C compiler of IAR Embedded Workbench version 6.5 (IAREW). The impact of both compilers in the reduction of code size and the time taken to execute the algorithm are compared.

RESULTS AND DISCUSSION

The grey scale images with size (C_m×C_n) = 100×100 and (D_x×D_y) = 50×50 are taken as cover and secret image, respectively so as to analyze the quality of stego image at full embedding capacity. In order to store all the images in its various forms with the above said sample image sizes in addition to the memory required for any temporary data storage, the algorithm demands around 85% of the available 32 KB on-chip local SRAM. The embedding scheme seems virtually fixed, because of the fixed number of bits embedded in each pixel of the cover image (K = 2). In reality, the total data embedding capacity for the taken image size is always depends on the number of header bytes to be sacrificed. Table 2 shows the sample values for multiple number of blocks with diverse sizes, number of header bytes to be spared and the respective embedding capacity.

The use of different keys to encrypt various blocks of secret data gives a linear rise to the number of blocks in the cover image thereby demanding more cover bytes to embed header information. Trade-off can be made between the rise in security level and reduction in data embedding capacity up on dividing the cover and data in to more number of segments. The various error metrics and performance metrics of the proposed method are compared in Table 3. The error metrics MSE and PSNR were calculated as said in the Eq. 5 and 6.

(5)

Table 2:	Sample block numbers, sizes, cover bytes and embedding capacity
Data embedding capacity is given by {[(Cm×Cn)-(r×HB)-CCB]×K} bits, where, number of blocks and HB = CCB = 5

Table 3:	Error metrics of proposed method

where, X_{i, j}-Stego pixel value Y_{i, j}-Cover pixel value.

(6)

As per the literature, the worst case PSNR value for K = 2 is noted as 38.59dB (Chan and Cheng, 2004). Improvements in image quality can be achieved by introducing the technique Optimum Pixel Adjustment Process (OPAP) on LSB substituted image, when K≥2. The algorithm was tested on 3 different standard cover images Cameraman, boat and house with same data image at full embedding capacity. Table 3 shows the error metrics MSE and PSNR values along with percentage of cover pixels altered in cover image for 4 different sample block sizes as given in Table 2.

The results obtained after the OPAP shows the apparent enhancement in error metrics. This is obtained at the cost of few bytes in code memory and a slight hike in cycles taken for execution. On an average 75% of the cover pixel values are getting altered after embedding. It is also clear from the results that the percentage of pixels altered in the cover does not contribute directly in picture quality rather, it depends only on the maximum possible number of pixels that can be adjusted to bring down the difference between the cover and stego pixels.

The performance of embedded code on any target device is analyzed with 2 major factors the memory footprint and speed. The prime constraint in the selection of target device is that the existing memory size should be large enough to fit in the application code and data as well. The data memory requirement is always application dependent and no programming technique can serve better in reducing this demand. The use of embedded processors for image staganography is typically restrained by its claim on data memory (RAM) the storage place for the cover and stego cover images. Some algorithms that wants to keep the cover image as static data may use a portion of program memory as the storage area for cover image. On the other hand storing the cover image in RAM helps the user for the dynamic selection of cover images before data embedding. The required amount of RAM memory for this algorithm is calculated as:

This calculation ensures the suitability of LPC2378 in satisfying the RAM requirement for the image steganography implementation with the above said image sizes.

The program memory size required for the application code is based on the compiler efficiency in generating the optimal output. The compilers of IDEs for embedded systems are tailored with the option for the selection of various optimization levels that can produce results favouring speed or space. Compiler based optimization techniques were previously analyzed for LWC by Janakiraman et al. (2014a, b). Here two well known IDEs KEIL MDK 4.7 and IAREW 6.5 are used to compile the code with 4 different levels of optimization. The snap shots of IDEs KEIL MDK and IAREW are shown in Fig. 3 and 4, respectively. The various optimization levels in KEIL and IAR compilers used are described in Table 4.

Fig. 3:	Snapshot of IDE-KEIL MDK 4.7

Fig. 4:	Snapshot of IDE-IA REW 6.5

Table 4:	Optimization levels of compilers

Table 5:	Compiler based optimization result analysis

Table 5 gives a detailed values of code sizes in terms of bytes and execution time in terms of cycle count obtained with four different optimization levels on both compilers.

The embedded code was written in such a way that, the code size remains constant irrespective of the image used as cover and when they are divided in to different number of blocks with various sizes. The cycle count that decides the execution time being unvarying for all the 3 cover images

used in the testing. Change in number of segments (blocks) in cover images varies the execution cycle count. The inference from the results Table 5 shows that in KEIL MDK, LEVEL-2 produces lesser code size than any other levels and LEVEL-3 takes fewer cycles for execution at the expenditure of few bytes in code size than in LEVEL-2. On the other side, IAREW results in more rate values of code size and execution cycles with LEVEL-0. Using LEVEL-2 in IAREW brings more than 50% reduction in execution cycles with a slight hike in code size than in LEVEL-0. As in the case for KEIL, LEVEL-3 of IAREW becomes the most optimal choice to cut back the execution cycles.

Analyzing the competence between the compilers of KEIL MDK and IAREW on footprint reduction, KEIL takes around 5.5-7.5% whereas; IAREW outperforms KEIL by taking only 2-3% of available on-chip FLASH memory of LPC2378. As given in the Fig. 5 using IAR C compiler helps to achieve around 50% space reduction with all optimization levels.

Also in terms of execution cycles shown in Fig. 6, IAR takes 50% lesser number of cycles than KEIL in all optimization levels except in LEVEL-3 where it atleast strives to get close with IAR.

All the results in Table 5 on execution time and code size are specified excluding the OPAP function, time load input images in RAM memory (cover and data) and time to display the images on GLCD. As the footprint of code without OPAP did not even require 10% of the existing FLASH memory, we can ignore the memory overhead produced by the inclusion of OPAP technique. In order to evaluate the timing overhead generated by the OPAP function we use the debugging aid, the Performance Analyzer provided by the KEIL MDK tool.

On comparing the results obtained from performance analyzer, the data embedding function consumes more than 80% of the total execution time with all the four different block numbers. The secret image encryption process takes level of considerable time around 10% where, the remaining modules altogether needs only less than 10%. The time that needs to complete the embed module and info_encryp module are based on the size of cover and secret images respectively which are considered as constant sizes in our implementation.

Fig. 5:	Code size KEIL vs IAR

Fig. 6:	Execution time KEIL vs IAR

As a result of this, even when the cover image is segmented in to more number of blocks, there is only a negligible amount of raise in execution time due to the function call overhead. The algorithm expects an output from the modules LFSR_3NOR and key_shufl for every segment of the cover image therefore, the execution time for these modules are decided only by the number of cover blocks and not by the size of cover image. This aspect makes the execution time for these module to raise linearly with the raise in number of cover blocks. On measuring the impact of OPAP, it is found around 30% raise in the execution time with improvement in stego image quality with 2 to 3 dB hike in value of PSNR. Changing the cover image when using the OPAP technique may lead to a slight difference in the total time taken by the code to complete the embedding process. This is solely depends on the number of stego pixels that needs correction from OPAP for error reduction.

Janakiraman et al. (2014c) proposed a byte wise XOR based encrypted embedding of secret image on gray scale cover image in method 2. The method 2 named as "Key Embedding and Encrypted Hiding" embeds the four trailing image pixels of cover image with the 8-bit key used for encrypting the secret image. In contrast, this method proposed in this study embeds the data, key and block size as well in to the cover image. On comparing the results from Table 6, the better imperceptibility on stego image achieved by the proposed method is represented with grater PSNR values with and without the use of OPAP technique.

Table 6:	Image quality vs embedding capacity (proposed method Vs Janakiraman et al., 2014c-Method 2)

Fig. 7:	Hardware implementation with image results displayed on GLCD, Top row: Boat (100×100) Left: Original cover, Right: Stego cover, Bottom row: Peppers (50×50), Original dataCentre: Encrypted data and Right: Retrived data

On the other side, the flexibility of the proposed algorithm which was not present in the Quad block embedding algorithm (Rajagopalan et al., 2012) in making tradeoff between the embedding capacity and algorithm complexity (using more number of blocks) has been also marked.

The code was actually targeted for smaller ARM devices with small RAM area in disparity to the work done by Stanescu et al. (2009) in a similar ARM device with external RAM interface. By utilizing the code compatibility among the various ARM versions, the code was also implemented on a board with CORTEX-A8 ARM processor. The processor is wired with a high resolution Colour Graphical GLCD, that provides 2, 30 and 400 dots with an active color matrix comprising 320 RGB columns and 240 rows. All the grey scale images were displayed on the 3.5 inch diagonally wide TFT LCD panel (GLCD) to test the intensity of scrawling on the encrypted secret image and visual imperceptibility on stego image. This was carried out only for the purpose of instant verification. In contrast, the GLCD was used as core module to provide security through user authentication by Janakiraman et al. (2014d). The snapshot of the embedded target board together with projected view of GLCD showing original and stego cover images of size 100×100 on the top row, along with plain, encrypted and retrieved secret data images of size 50×50 in bottom row is provided in Fig. 7.

CONCLUSION

The results obtained for the implementations shows the possibility of embedding encrypted data on grey scale images without the exchange of a separate key prior to the exchange of stego cover. The image quality on stego image can be boosted to a considerable extent using OPAP method when K>1. Dividing the cover image into any number of blocks does not have any impact on the footprint or code size of the program. The implementation concentrated only on the use of on-chip memory resources for the purpose of implementing steganogarphy on grey scale images. This will result in the significant reduction of the memory accessing time when compared to external memory accesses and also helps in minimizing the cost and space of embedded hardware. On comparing the results, this study recommands the use of IAR C compiler (IAREW version 6.5) for better optimization in terms of both space and time. On the other hand, KEIL MDK version 4.7 provides more debugging mechanisms like Execution profiler, Performance analyzer, etc. that facilitates better result analysis. This paper shows a practical method to provide a low cost dual level of security through a combination of crypto and stego algorithm on data communication network using ethernet or CAN module built in the LPC2378 embedded device with ARM7 core, without any demand on additional resources. Based on the demand on speed by the application, the LPC2378 can run upto the maximum frequency of 72 MHz. Finally, the error metrics to compare the quality of stego image with cover image and performance metrics with respect to execution time are found to be in pahse with the ranges suggested in literatures.

ACKNOWLEDGMENTS

Authors wish to thank SASTRA University for providing infra structural support through Research and Modernization fund Reference No. R and M/0026/SEEE-010/2012-13.