Welcome!

Cloud Security Authors: Pat Romanski, Elizabeth White, Zakia Bouachraoui, 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.

Overview
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.

Conclusion
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
Atmosera delivers modern cloud services that maximize the advantages of cloud-based infrastructures. Offering private, hybrid, and public cloud solutions, Atmosera works closely with customers to engineer, deploy, and operate cloud architectures with advanced services that deliver strategic business outcomes. Atmosera's expertise simplifies the process of cloud transformation and our 20+ years of experience managing complex IT environments provides our customers with the confidence and trust tha...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Never mind that we might not know what the future holds for cryptocurrencies and how much values will fluctuate or even how the process of mining a coin could cost as much as the value of the coin itself - cryptocurrency mining is a hot industry and shows no signs of slowing down. However, energy consumption to mine cryptocurrency is one of the biggest issues facing this industry. Burning huge amounts of electricity isn't incidental to cryptocurrency, it's basically embedded in the core of "mini...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
The term "digital transformation" (DX) is being used by everyone for just about any company initiative that involves technology, the web, ecommerce, software, or even customer experience. While the term has certainly turned into a buzzword with a lot of hype, the transition to a more connected, digital world is real and comes with real challenges. In his opening keynote, Four Essentials To Become DX Hero Status Now, Jonathan Hoppe, Co-Founder and CTO of Total Uptime Technologies, shared that ...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Every organization is facing their own Digital Transformation as they attempt to stay ahead of the competition, or worse, just keep up. Each new opportunity, whether embracing machine learning, IoT, or a cloud migration, seems to bring new development, deployment, and management models. The results are more diverse and federated computing models than any time in our history.
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Where many organizations get into trouble, however, is that they try to have a broad and deep knowledge in each of these areas. This is a huge blow to an organization's productivity. By automating or outsourcing some of these pieces, such as databases, infrastructure, and networks, your team can instead focus on development, testing, and deployment. Further, organizations that focus their attention on these areas can eventually move to a test-driven development structure that condenses several l...
The graph represents a network of 1,329 Twitter users whose recent tweets contained "#DevOps", or who were replied to or mentioned in those tweets, taken from a data set limited to a maximum of 18,000 tweets. The network was obtained from Twitter on Thursday, 10 January 2019 at 23:50 UTC. The tweets in the network were tweeted over the 7-hour, 6-minute period from Thursday, 10 January 2019 at 16:29 UTC to Thursday, 10 January 2019 at 23:36 UTC. Additional tweets that were mentioned in this...