Stream security particularities in Java

Regarding numerous threats connected with sending and storing confidential data, there is a problem of assuring the efficiency. As an answer to those needs, we discuss the SUN‘s Java Virtual Machine mechanism provided to assure security to a single object. Thanks to the mechanism of serialization in Java, it is possible to provide secure solution. In this paper, we compare the efficiency of algorithms such as DES, Blowfish, AES, RSA and ECC as means of securing serialization of an object.


Introduction
Concerning increasing threats including storing and transferring confidential data, there is a growing demand for secure solutions. The Java Virtual machine provided by Sun uses most of the modern ways of securing the transmission of data. As every object can be sent as a serialized stream, there are mechanisms that allow its encryption. Since the amount of data being encrypted rises, choice of an efficient algorithm becomes crucial. In this paper we examine some particularities of the encryption of objects graph 1 byte stream. We have covered some areas that can also be found in [1].

Main goals
The main objective of the paper is to present the results of tests made as a part of a larger project. The project goal is to provide platform independent security architecture for sensitive data transfer. The conclusions from this paper are being used for the project development.
The following questions are to be answered: 1. What are the cryptographic aspects of Java streams?
2. What is the time efficiency regarding stream cryptography using symmetric algorithms? 3. What are the differences comparing symmetric and asymmetric cryptography algorithm implementations in Java? This paper does not intend to discuss the accuracy of the time measurement. Even though it is possible that some discrepancy will occur, it is believed that this will be eliminated by more precise hardware timing sources that will hopefully be soon designed and utilized by operating system calls.

Testing environment
The choice was the linux because of the Windows JVMcalls to System.nanoTime() is implemented using the QueryPerformanceCounterQuery PerformanceFrequency API (if available, else it returns currentTimeMillis * 10 6 ). As its default 10 ms timer interrupt period can be modified by application programs using the timeBeginPeriod/timeEndPeriod API's there is no guarantee that a wanted period will be supported, moreover its accuracy has been questioned in some reports [2]. The testing procedure for all tests has been performed on 100 different objects of approx. 5KB each. The testing architecture was as follows: -Hardware: Intel ® Core TM 2 Duo E6600 @ 2.40Ghz, 2GB RAM -Software: Linux (2.6.23.9-85), Fedora 8, Sun JDK 1.6.0_03 3. Byte distribution in streams As a security must, the information sent throughout the potentially hostile environment e.g. the Internet, should be as secure as it is possible regarding the efficiency aspect. One of the security bases is the distribution of data structure along the transfer domain (i.e. all possible values of the information byte). At the basic level, the byte distribution is the issue. That is why in this paper we present the Java basic stream mechanism analysis.

The regular stream distribution
To find the distribution of byte values in the transmitted stream an external class was made. Its purpose was to check each byte of data from the stream and add it to an appropriate analyzing structure. As an obvious way of representing the results, is to treat the byte values of a stream as 0 to 255 codes 2 .
As a number of serialized objects were sent as a stream the statistics displayed in Figure 1 were obtained. It can be clearly seen that the byte distribution provided is unacceptable regarding the frequency analysis attacks that can take advantage of this stream structure. This behaviour is not permanent but the tendency for such a disproportion holds across multiple tests. From the test results, it can also be claimed that the majority of the values (i.e. over 80%) from the first group obtain zero value.

Entropy provided by cryptographic mechanisms
As the above results for pure stream proves that it appears to be insecure, some tests have been performed on securing it by using the CipherOutput/ InputStream classes provided by the JCA/JCE architecture. For this purpose the Bouncy Castle [3] provider has been used. The same tests have been performed for the streams secured with the DES, TripleDES, Blowfish and AES algorithms as the most widespread. The acquired results displayed in Figure 2 provided much more reliable byte distribution regarding the security aspect. As the figures are not as clearly visible as for the pure stream some statistical analysis needs to be applied. For the perfect byte distribution, the standard deviation should be null and each byte value in this case would have the average value of one out of 256. This of course is just a theory, because the results (Figure 3) for the encryption of a stream provide much better byte distribution than the pure stream did, but not to such an extent. Some tests have also been made on the byte distribution provided by the RSA. Of course, it needs to be mentioned that the RSA is not a kind of cipher used for a stream cryptography. Because of its particularities, the length of a message cannot be longer than the key length. Therefore for the key of 1024 bits the message can be, as in the examined case, maximum 117 Bytes 3 . To avoid the byte distribution provided by the message itself the stream bytes were all zeros. RSA is a cryptosystem used just for symmetric algorithms key distribution, therefore it is combined with one of the symmetric ciphers.

The System.nanoTime()
To measure the time consumption of an algorithm, to some extent, it would be the best to measure it natively. For that purpose the use of Java Native Interface would be a must. Although this would be the best for watching the efficiency of bytecode itself JNI could provide extra overhead to JVM. That is why the solution provided by System.nanoTime() is considered in this document.
The System.nanoTime() method according to [4] provides the most precise available system timer, in nanoseconds. The value returned represents nanoseconds from some fixed but arbitrary time e.g from boot up or JVM start. It is also claimed that this method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. Its general issue is that it only provides nanosecond precision, but not necessarily nanosecond accuracy.
For this kind of JVM functions, it would be preferable to use the finest grained clock possible. For that purpose, the POSIX clock_gettime() with the CLOCK_MONOTONIC, as described in [5] and [2], seems to be the right choice. As it is known that the clock_gettime() is supported in current linux libraries and also according to [6] sufficiently recent versions of GNU libc and the Linux kernel supports the CLOCK_MONOTONIC clock as well. As this feature is not supported in most distributions, including the testing environment, the System.nanoTime() call relies on alternative, after [7], function gettimeofday() 5 as described in [8], that works with microseconds accuracy depending on a system.
Regarding this and as a conclusion from discussion [2], we have chosen the System.nanoTime() to manage with most of the tests workload, on measuring the elapsed times. What also needs to be mentioned is that the disk utilization 6 was not participating in the testing procedures.

The time efficiency of symmetric algorithms
The tests performed on time consumption of each symmetric algorithm were all based on the same scheme. Every encryption-decryption phaze was divided into some partial procedures (i.e. their times) evolved from the cryptographic and JCA/JCE architecture. Each test consists of 100 7 repetitions of each partial procedure of the entire process. 5 It has been found that the native operation executes the following: nanoseconds = (seconds * 1000000) + microseconds) * 1000 As the strace analyze and the function code [9] has been analyzed. 6 As a potential source of overhead. 7 The scheme modified to 1000 repetition model did not change the general tendency.

The time efficiency -results
As the tests were performed the following results have been obtained.

Fig. 5. Time consumption of the DES algorithm
There is only one particularity in the time efficiency of the first two algorithms that can also be found in all of the tested algorithms, meaning the time spent on key generation. It can be clearly seen that it is the main factor that decides for the entire process time. It might not be unexpected regarding the fact that it includes the generation of secure random, but it is important to note how significant it is regarding the entire process 8 .

Symmetric and Asymmetric algorithms comparison
The same testing procedure was applied to the RSA asymmetric cryptosystem. The results presented in Figure 9 display however, some interesting particularity that comes from the RSA algorithmic characteristic. From the theory of the RSA we know that the private exponent of the private key is much larger than the public exponent. Therefore using the RSA private key causes slower computations than the public key.

Elliptic Curve Cryptography
Following [10] and key length ( Figure 10) it must be claimed that combining it with the results of performed tests ECC becomes the most suitable scheme for securing data. As the time of key generation in the tested algorithms became the main factor; reducing it while retaining the same cryptographic strength would be the optimal solution.

Conclusions
Along the performed tests it has been shown that regarding the symmetric algorithms comparison, the AES algorithm with this Java implementation provider, has outperformed other algorithms in terms of better byte distribution and also presented that time efficiency has given better results.
Thanks to preserving RSA keys' size disproportion particularity in Java implementation, it can be used for further project work to allow ciphering on clients with limited computational resources. Thanks to numbers achieved from those tests, it can be confirmed that the RSA is also much slower comparing to the symmetric ciphers. Further work needs to be done on promising comparison for asymmetric cryptosystems with the NIST results for ECC; ECC advantage needs to be confirmed regarding the Java ECC architecture and implementation.