Cloud Security Authors: Pat Romanski, Zakia Bouachraoui, Elizabeth White, Yeshim Deniz, Liz McMillan

Related Topics: Java IoT, Cloud Security

Java IoT: Article

Java Security: Beyond Code Safety

Java Security: Beyond Code Safety

In an article entitled Implementing a Security Policy (Java Developer's Journal, Vol. 2., Issue 8), Qusay Mahmoud wrote on the practical uses of the Java SecurityManager class.

Starting with JDK 1.1, Java provides a number of classes and interfaces for implementing a comprehensive security policy. These include cryptographic interfaces for signature production and verification, cryptographic checksums as well interfaces for access control. This article focuses on practical uses of the cryptographic interfaces of JDK 1.1, including their use in creating and verifying the origin of trusted applets.

Many organizations are attempting to harness the connectivity power of the Internet to conduct real business on a global scale and earn more money. In order for electronic business to flourish, the infrastructure must provide a basic framework of trust. The elements of trust include provisions for:
1. Identification and Authentication - The process of ascertaining the identity of one party to another
2. Authorization and Access Control - The process of granting and denying the rights to a party to perform a certain operation
3. Privacy-protection - The assurance that the details of the transaction can not be revealed to a third party.
4. Integrity-protection - the assurance that a receiving party would reject a transaction that is accidentally or maliciously corrupted
5. Non-repudiation - The assurance that an entity cannot deny being a party to a transaction after it voluntarily engages in that transaction
6. Audit - A means of securely keeping a detailed record of events for possible future examination

Java is rapidly becoming the language of choice for developing and deploying Internet-based applications. The longevity of Java depends on many factors, including the availability of built-in tools to implement a security policy that reflects the needs of individual organizations.

Trust Model before JDK 1.1
From its very inception, the Java language has implemented a simple and somewhat effective trust model. This model - known to Java developers as the sandbox - provides a binary choice within the runtime environment: trust everything that is local, but do not trust anything that is downloaded. In other words, the Java runtime completely trusts each and every Java application and completely restricts each and every downloaded Java applet. The Java runtime restricts applets from accessing local files. This restriction manifests itself in several ways, including the restriction to load a local class, to link with a local library and to read and write local files. Implementations of the JDK within each browser modify the SecurityManager class to provide different degrees of access to downloaded applets. However, the trust model remains binary.

The Sandbox Dilemma: To Use or Not to Use
Experience shows that from a security policy standpoint, enforcing the sandbox model is very important. The sandbox protects you from malicious attacks and misbehaving applications that can delete your files, misuse private information or consume your system resources. Simultaneously, most applications need to interact with users in a personalized way. This means that in order for an applet to provide a useful function - especially in the context of electronic business - it does need access to some local resources.

Solutions to the Sandbox Dilemma
JavaSoft addresses the sandbox dilemma in two releases of the JDK. JDK 1.1 allows the originator of an applet to digitally sign the applet (see the sidebar for a primer on digital signatures). The digital signature provides a highly tamper resistant fingerprint of the applet. The client who downloads the applet can choose to trust the originator and allow it to access local resources (files, network connections, etc.). Therefore, a client can treat each applet differently based on its digital signature. However, the trust model for a given applet remains binary. JavaSoft addresses this problem in JDK 1.2 with fine grain access control. JDK 1.2 introduces the concept of protection domains, which allows a client to specify exactly which resources a given applet may access and for what reason (read, write, connect, etc.). JDK 1.1 Tools for Applet Signing

JDK 1.1 provides two tools for applet signing: javakey and jar. Use javakey to create identities and load them into your identity database. Once you create an identity, you can designate it as a trusted identity. Applets that are signed by a trusted identity are trusted applets. JDK 1.1 treats trusted applets as local applications: a trusted applet has access to everything a local application can access. Using javakey you can also create a signer identity. A signer is an identity with a private key. You create a signer on the server side before signing the applet. Table 1 shows the various options of javakey.

Even though jar is not a security tool, it is very useful for packaging a series of files, including Java classes, into a single downloadable entity. The jar command provides the same function as the UNIX tar command. Table 2 shows the various options of jar.

Steps in Creating a Signed Applet
In order to create a signed applet, you need to take the following steps. Listings 1 and 2 show an example of each step. The string ambrosia is the prompt of the system that was used to generate these examples.

Step 1: Create a signer identity and generate key pair.
Using javakey. you would create a signer and trusted identity. In listing 1, with the command [1] we create a signer identity called OpenHorizon. After creating a signer identity, you need to generate a public/private key pair for that identity. The algorithm you choose for the signing and verifying signatures and length of the key are important parameters contributing to the overall security of your environment. In listing 1, with command [2] we choose the Digital Signature Algorithm (DSA) with a key length of 1024 bits. The public and private keys are stored in two files called oh.pub and oh.priv respectively. Note that it is extremely important to protect the private key file.

Step 2: Generate a certificate for the signer
Every signer must have its public key certified. In a real Public Key Infrastructure (PKI) environment, a Certification Authority (CA) issues a certificate which binds a signer's identity to the signer's public key. The CA itself may have a certificate issued to it by another, higher authority CA. This is called chain-of-trust and is not supported by JDK 1.1. In listing 1, with command [4] we create a self-issued certificate: a certificate issued by the identity OpenHorizon for itself. Note that certificates are issued according to a certificate directive file. The certificate directive is shown in listing 1, with command [3]. It specifies, among other information, a 1 year validity period, a serial number (1100) and the name of the file where the certificate will be stored (oh.cert).

Step 3: Create and sign the archive
You would follow the procedures in steps 1 and 2 to prepare your system for signing applets. Follow the procedures in steps 3 and 4 every time you need to create and deploy a signed applet. In listing 1, with command [5] we first create a jar file of all classes that comprise a sample of a software called Ambrosia. We call the target jar file AmbrosiaSamples.jar. Using command [7], we sign the jar file with the private key of an identity whose name appears in a signature directive file (listed with command [6]). The signature file name that appears at the end of the signature directive file is used to create the signature as an individual file (OHSig.DSA). The signature file is included in the jar file.

Step 4: Deploy signed archive on the web server.
Javakey creates a file with the same name (AmbrosiaSamples.jar) and the extension .sig. We rename Ambrosia.jar.sig to Ambrosia.jar, which is a more suitable name for deploying the signed classes on the web server. In listing 1, with command [8] we rename the jar file. Listing 2 shows the HTML file for one applet (ohpub.class) embedded in the signed jar file.

Configuring the Client
The client must be configured to recognize and validate the signer of the applet. Listing 3 shows the javakey commands you can use to configure the client. You may have to use a different set of commands depending on your browser. The client must obtain the certificate file (oh.cert in this example) before loading it to the identity database (listing 3, command [9]).

The Java Cryptographic Architecture
In this section of the article we focus on the Java Cryptographic Architecture (JCA). Figure 1 shows the basic hierarchy of the JCA. There are three classes that form the foundation of the JCA: KeyPairGenerator, MessageDigest and Signature. You may notice that the JCA does not include any classes for encryption. The reason is that including encryption classes or interfaces would make the JDK non-exportable. Therefore, JavaSoft has elected to provide an adjunct package called the Java Cryptographic Extensions (JCE), which is only available to customers in the United States and Canada. The JCA is based on the notion of Cryptographic Package Providers (CPP). As such, the JDK itself simply provides engine classes and interfaces. Engine classes and interfaces may be implemented by one or more CPP's. JDK 1.1 comes with a default implementation for the DSA, MD5 and SHA algorithms. Other CPPs can provide implementations for the same or new algorithms. CPPs may be installed statically at the time of JDK 1.1 installation. You can also use methods of the java.security.Security class to dynamically manage providers.

Getting an Instance of an Engine Class
All three engine classes have a factory method that allows you to instantiate an object with a specified algorithm and a specified provider. For example, in listing 4 line 9 we obtain an instance of the DSA signature algorithm provided by the default CPP (in this case, SUN). If desired, one can use another version of the getInstance method to name a specific provider.

Signing Data and Verifying Signatures
The Signature class can be used to both sign data and verify the digital signature of the data. Consequently, when you instantiate a Signature object you must initialize it to be either in a SIGN state or a VERIFY state. Figure 2 illustrates the states of the Signature class. Once in a given state, you can supply the Signature class with as much data as you wish and with as many update method calls as you wish. After you have supplied all the data, you would invoke either the sign or the verify method to perform the corresponding operation. After the data is signed or verified, the Signature object returns to an uninitialized state.

Digitally Signing Data
Listing 4 shows a partial code segment for digitally signing data. Lines 1 and 2 import the security packages needed for signing data. Lines 3 and 4 define two byte arrays: one is the input data to be signed, and the other is the digital signature. At line 9 we instantiate a Signature object which implements the DSA algorithm by the default provider (i.e., SUN). Line 10 places the object in the SIGN state. Line 11 feeds the data to the object and line 12 produces the digital signature. Note that if we were receiving the data in chunks, say from a user, we could call the update method as many times as required until there was no more data. Also note that the private key that is used to sign the data must be loaded (not shown in the code) prior to calling the initSig method. Use methods of KeyPair and Key interfaces to set the private key.

Verifying the Digital Signature
Listing 5 shows a partial code segment for verifying the digital signature of some arbitrary data. Lines 1 and 2 import the security packages needed for verifying the digital signature on the data. Lines 3 and 4 define two byte arrays: one is the input data whose digital signature is to be verified and one is the actual digital signature. Line 6 defines a boolean that will be set by the verify method to true or false depending on whether the signature is valid or not. At Line 10 we instantiate a Signature object which implements the DSA algorithm by the default provider (i.e. SUN). Line 11 places the object in the VERIFY state. Line 12 feeds the data to the object and Line 13 verifies the digital signature. Again, note that if we were receiving the data in chunks, we could call the update method as many times as required until there was no more data. Also, note that the public key that is used to verify the digital signature must be loaded (not shown in the code) prior to calling the initVerify method. Use methods of KeyPair and Key interfaces to set the public key.

JDK 1.1 provides an excellent starting point for building a secure and trustworthy infrastructure. Java security is much more than code safety and sandboxing. With JavaSoft's plan to provide more security classes and interfaces, either as part of the JDK or as adjunct packages, Java will solidify its position as the language of choice for developing and deploying Internet-based applications.

More Stories By Jahan Moreh

Jahan Moreh is the chief security architect at Open Horizon, Inc. (www.openhorizon.com). He is a frequent speaker on the topic of Java security at various conferences. Additionally, he is a senior member of the teaching staff at UCLA's department of Information Science where he teaches classes in distributed system security and CORBA.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

IoT & Smart Cities Stories
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Early Bird Registration Discount Expires on August 31, 2018 Conference Registration Link ▸ HERE. Pick from all 200 sessions in all 10 tracks, plus 22 Keynotes & General Sessions! Lunch is served two days. EXPIRES AUGUST 31, 2018. Ticket prices: ($1,295-Aug 31) ($1,495-Oct 31) ($1,995-Nov 12) ($2,500-Walk-in)
IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.