There has yet to be a ruling on Google’s bid for a mistrial, and Oracle today filed to divorce from the portions of the case already heard, a motion likewise still up in the air. The next phase of the trial will likely surround further classification of the 37 Java APIs in question, a ruling on whether or not any of them are actually copyrighted, which would lead to a better look at the issue of fair use.

Comments

Oracle has always contended that the Java APIs used by Google are so intricate that they could be considered to be a protected creative work. Jacobs somewhat dramatically described said Java APIs as being akin to a musical composition, – “It’s magical. It’s like painting.” Google has always said that none of this mattered, as Java falls under fair use, and has claimed that the lawsuit was an attack on open-source Java content from the start. Jacobs asserted that Google has been using this sort of thing as a cop out, and was well-aware that their manipulation of Java might’ve gone beyond what open-source was intended for – which seems to go along with reports of Google CEO Larry Page’s demeanor as he’d taken the stand. Page remained elusive when asked about any company emails concerning the APIs, plainly stated that he “didn’t remember.”

Earlier speculation that Oracle might demand that Google change the Android code altogether were far-fetched – the company wants Android to get a license for Java, and to admit they essentially stole the APIs, since they were aware a license would be required in the first place. It would appear Google might’ve taken a gamble, lost, and now might have to plainly pay for what it would’ve had to pay for in the first place, sans any court proceedings. Android exec Andy Rubin even testified that Google wanted Sun (the developer of Java before Oracle took over) to “throw away their standard license,” and “develop a new license that was specifically what we’re looking for.” Then Rubin turned around and stated that Google didn’t think they needed a license.

Presiding Judge William Alsup predicts the jury might be back within the next couple of days. This will be interesting – If Google loses, the trial will eventually progress to the stage where fines are handed out. The number could be outrageous.

To recap, Oracle is suing Google over using Java in developing its Android OS, and seeks damages, which could be in the hundreds of millions of dollars, and more seriously, seeks to have the internet search giant change the code of the operating system. Google maintains that no infringement was committed, and that Oracle’s lawsuit is an attack on the open-source Java community. As another hit to Oracle, 5 of the patents it originally held at the time of the initial complaint have been invalidated by the U.S. Patent and Trademark office, and another one is set to expire.

The main point of contention will be whether or not APIs (application programming interfaces) can be copyrighted, which could set a precedent for developers besides Google, and the trial could cover three stages – copyright claims, patent claims and a third stage to asses any damages to be awarded to Oracle, if the company wins the first two segments. If the final stage is met, damages will depend on whether or not Oracle can prove that Google willfully violated any patents, which automatically triples fines.

While both sides agree that Java is open-source and can’t be infringed upon, Oracle asserts that Java APIs are so complex that they can be considered to be protected like a creative work of art would be. Oracle also asserts that Google manipulated the APIs to build “not a compatible version of Java, but an incompatible one.” Google’s lawyers responded, stating, “Without the APIs, the Java programming language is deaf, dumb and blind.”

High level executives from both companies are expected to participate in trial, and both outfits will need to present video presentations to better convey some highly technical discussion to the members of the jury. It will be interesting to see how the case plays out.

Comments

SSLServerSocketFactory sslServerSocketFactory = sslContext.getServerSocketFactory();
SSLServerSocket sslServerSocket = ( SSLServerSocket ) sslServerSocketFactory.createServerSocket( port );

This SSLServerSocket can be used in the same way as any ServerSocket, including using the accept() method to begin listening for incoming connections. The code for the client-side should look familiar as well.

SSLSocketFactory sslSocketFactory = sslContext.getSocketFactory();
SSLSocket sslSocket = ( SSLSocket ) sslSocketFactory.createSocket( host, port );

No big surprises here. The createSocket method does the same thing it does for a regular Socket object; it opens up a connection to the specified host in the designated port. The only difference is that it encrypts data sent through it, and decrypts data it receives.

When you are setting up the server-side code, there are two settings in particular that you should consider when you create the socket. These are setWantClientAuth() and setNeedClientAuth(). Both methods take a boolean value as their only argument.

sslServerSocket.setWantClientAuth( true ) will tell any clients who are connecting to show their credentials, in the form of the TLS/SSL handshake. If the client does not provide credentials, then the connection will continue as normal. sslServerSocket.setNeedClientAuth( true ) will request client credentials as well, but if the client does not provide them, the connection is severed. If you are creating an application where having a secure connection is important, this is the method for you.

As you have seen over the course of this series, there are several steps to take when setting up a secure socket connection. None of these steps are inherently difficult, but they must be executed correctly in order to ensure data security. Once you finish the setup, it is just using normal sockets to communicate again, but with the peace of mind that comes with knowing you are safe from third parties intercepting your data.

The first thing we want to do is set up a SecureRandom, which is a random number generator random enough that it makes decrypting data without the private key extremely difficult.

SecureRandom secureRandom = new SecureRandom();
secureRandom.nextInt();

The call to nextInt() primes the number generator to start producing random numbers. We now need to create two KeyStore objects to pull in the public and private keys we created in the last article.

KeyStore publicKeyStore = KeyStore.getInstance( “JKS” );
publicKeyStore.load( new FileInputStream( “/path/to/client.public” ), “keystorePassword”.toCharArray() );

KeyStore privateKeyStore = KeyStore.getInstance( “JKS” );
privateKeyStore.load( new FileInputStream( “/path/to/server.private” ), “keystorePassword”.toCharArray() );

The above code uses the filenames for the server-side code. If you are writing the client-side code, you will need to use ”/path/to/server.public” and ”/path/to/client.private” instead. “keystorepassword” is the password you set for the keystore when you created it using keytool. When we create the KeyStore object, we are getting an instance from the static object with type “JKS”, which is simply the keystore format. Other formats exists, such as “JCEKS” and “PKCS12”, but “JKS” is the standard type used.

Now that we have our keys loaded into our application, we can create the object that actually authenticates the party on the other end of the socket, the TrustmanagerFactory.

TrustManagerFactory trustManagerFactory = TrustManagerFactory( “SunX509” );
trustManagerFactory.init( publicKeyStore );

The TrustManagerFactory is created like the KeyStore object, from the static class object. It is created with type “SunX509” which is the name of the trust management algorithm we are using in this example. We then load the public keystore into the trust manager. Next is the KeyManagerFactory, which is used to do all the actual encoding and decoding of data.

KeyManagerFactory keyManagerFactory = KeyManagerFactory.getInstance( “SunX509” );
keyManagerFactory.init( publicKeyStore, “keyStorePassword”.toCharArray() );

When creating the KeyManagerFactory, you can see we used “SunX509” again. You might also notice that we need the keystore password again. This is simply because when we used to password to set up the KeyStore object, it was only used to verify the integrity of the keystore, and now we are actually unlocking the keystore for use.

The final step in creating our secure socket connection is to create an SSLContext object.

SSLContext sslContext = new SSLContext.getInstance( “TLS” );
sslContext.init( keyManagerFactory.getKeyManagers(), TrustManagerFactory.getTrustManagers(), secureRandom );

The SSLContext object is created with the “TLS” protocol (which of course stands for “Transport Layer Security”), and initialized with the key managers and trust managers from the factories we created above, and also the SecureRandom we created. In our next installment we will use this SSLContext to create the sockets which will communicate with each other securely over the network.

keytool -genkeypair -keystore server.private

*Note: if you are using Java SE that is below version 6, you will have to use -genkey instead of -genkeypair.

You will be asked a series of questions which will be used to create your certificate. Make sure to make a note of your keystore password and your key password, as you will be needing them later. Do the same thing to create the client’s private key, only using -keystore client.private instead.

Now you will need to extract the public keys from the private keys. This also uses the keytool command.

keytool -export -keystore server.private -file temp.key
keytool -import -keystore server.public -file temp.key

Exporting will prompt you for the private keystore’s password, and importing will ask you to create a new password for the public keystore. Be sure to delete temp.key once you are finished. Repeat these steps to create the client.private keystore and extract the client.public keystore from it.

Once all this is finished you will have all 4 keystore files that you need to fully encrypt your network communications. These files need to be put in the correct places in order to be effective though. When you distribute your code, you will have 2 executables, one for the server and one for the client. The server needs to have it’s own private key and the client’s public key, and the client needs to have it’s own private key and the server’s public key, as shown in the table below.

In part 5 of this series, we will begin integrating these keys into our basic socket client/server program and preparing to send encrypted data.

    public void connect() {
        String host = “localhost”;
        int port = 54321;

        try {
            // create a connection to the server
            Socket socket = new Socket( host, port );

            // setup the input/output connections
            BufferedReader socketIn = new BufferedReader( new InputStreamReader( socket.getInputStream() ) );
            PrintWriter socketOut = new PrintWriter( socket.getOutputStream() );
            BufferedReader stdIn = new BufferedReader( new InputStreamReader( System.in ) );

            //interact with the server
            System.out.println( socketIn.readLine() );
            socketOut.println( stdIn.readLine() );
            socketOut.flush();
            System.out.println( socketIn.readLine() );

            //close the socket
            socketIn.close();
            socketOut.close();
            stdIn.close();
            socket.close();
        } catch ( UnknownHostException ex ) {
            System.out.println( ex.toString() );
        } catch ( IOException ex ) {
            System.out.println( ex.toString() );
        }
    }

The client code is a little less complex than the server code, in that you don’t need to worry about the listening aspect of the connection. All we are doing here is opening a socket that is connecting to the given host and port.

As you can see, I have added a new input source, stdIn. This has nothing to do with the sockets, but what the sockets are doing. If you remember from part 2, the server will greet the incoming connection and ask for the user’s name. This client code will echo that greeting and allow the user to input their name to be transmitted through the socket and back to the server.

Part 4 of this series will gear up to the fun stuff, actually using JSSE to encrypt the data being sent over the network.

    public void listen() {
        int port = 54321;

        try {
            // create the listening socket
            ServerSocket serverSocket = new ServerSocket( port );
            while (true) {
                // listen for a connection
                Socket socket = serverSocket.accept();
                System.out.println( "Incoming connection from " + socket.getInetAddress() );

                // setup the input/output for the newly connected socket
                BufferedReader socketIn = new BufferedReader( new InputStreamReader( socket.getInputStream() ) );
                PrintWriter socketOut = new PrintWriter( socket.getOutputStream() );

                // interact with the client
                socketOut.println( "Thank you for connecting! What is your name? " );
                socketOut.flush();
                String name = socketIn.readLine();
                socketOut.println( "Hello " + name + "!" );
                socketOut.flush();

                // close the socket
                socketIn.close();
                socketOut.close();
                socket.close();
            }
        } catch ( IOException ex ) {
            System.out.println( ex.toString() );
        }
    }

You can see in the code that we are creating a new ServerSocket object. The accept() method of this object will block until a client attempts to make a connection, then will return the socket connection that is created. We then create the input and output streams for sharing data with the client. Once we have finished our interaction, we close both streams and the socket itself. An IOException is thrown if the socket fails to be created for any reason.

Part 3 of this series will continue our venture into basic socket communication.

To understand what JSSE does, we first have to understand what a socket is, and what it does. A socket is basically just a virtual communication port that is used to transfer data between two machines. A socket on one machine connects to a socket on another machine and they can transmit data between each other. Super simple, right?

As we know, if data is sent over the internet it is susceptible to being intercepted by third parties. In order to protect our data from being read by those with malicious intent, we utilize JSSE to encrypt the data at the starting point, use sockets to transmit and receive that data, and JSSE again to unencrypt the data at the end point. This is done by utilizing public-key cryptography.

In public-key cryptography, each computer has two encryption keys, a private key that only it knows and a public key which is known by the other computer. Using our client/server relationship as an example, the client will have the client’s private key and the server’s public key. The public key is used to encrypt the data and, once encrypted, that data can only be decrytped by the server’s private key, thus even if a third party has the public keys, it cannot use them to retrieve the unencrypted data from the transfer.

Now that we have a basic understanding of sockets and encryption (a very, very basic understanding) we can start looking at actually using sockets to send information back and forth across a network. Look for part 2 of this series to start using sockets to transmit unencrypted data across a network, and further parts to add the encryption layer to that exchange.

One big addition to the platform is the integration of Red Hat’s Jboss Tools, a set of Eclipse plugins, that will allow developers to do all of the coding, maintenance and launching of applications right on the cloud. Not only are they not supporting that, but also Maven, which allows for easy Java project management, and Jenkins, which as they state on their site “is an award-winning application that monitors executions of repeated jobs, such as building a software project or jobs run by cron.”

They are implementing the full software development life-cycle now, which means that developers will never have to to be tied down to a home server again, as their data can always be accessed as long as they have some sort of connection. This is pretty big, considering that Java is not often something you think about when you think of cloud computing. The addition of Maven and Jenkins allows a great deal of automation as well, and while these jobs could be done on in-house infrastructure, it affords developers more time to do what they are good at when they don’t worry about their maintaining the infrastructure.

If you are interested in OpenShift and arent using Red Hat, go on over to RH’s site and check it out. Then after that, or if you had RH in the first place, head on over to http://openshift.redhat.com and see if the platform is right for your needs.