Tuesday Sep 17, 2013

Signing applet code does not grant all-permissions (since 7u25)

There are two levels of authorization for Java applets and web start applications: sandboxed, where the application is limited in terms of actions it can take on users' computers, and all-permissions, where applications operate as though they were native, with full access to the system and its resources.

In the old days of Java 6 and early days of Java 7, the rule was that only applications that required all-permissions needed to be signed. Since Java 7 update 21 (April 2013), you are able to (and encouraged) to sign all types of applications: sandbox and all-permissions. The intent of this is that code signatures from trusted certificate authorities provide a means of authentication for end users, so that they can know who actually wrote the application.

Java 7 update 25 also introduced two new attributes within a jar's Manifest file aimed at Preventing RIAs from Being Repurposed. By having these attributes within the signed jar, attackers cannot make any adjustments to the permissions level without invalidating the signature. An example of the META-INF/MANIFEST.MF file with these attributes would be:

Manifest-Version: 1.0
Created-By: 1.7.0_25
Permissions: sandbox
Codebase: https://example.com

Name: Clazz.class SHA1-Digest: HASHSTUFF=

Beginning January 2014, code signatures and use of the Permissions attribute will be mandatory for all Applets and Web Start applications. The Codebase attribute will remain optional, as ISVs may not know this information beforehand.

These changes create a separation between three areas of trust:

  1. Identification: provided by the application, stating its publisher.
  2. Authentication: automatic by the JRE, the code signatures within JARs is verified against public certificate authorities and dynamically updated revocation lists.
  3. Authorization: once authentication has occurred, allow the application to ask the user for a specific set of permissions.

For additional information about the role of code signatures, sandboxed or not, see our previous blog entry, Code signing: Understanding who and when.

Monday Sep 09, 2013

New security requirements for RIAs in 7u51 (January 2014)

Java 7 update 51 (January, 2014) intends to include two security changes designed to enhance authentication and authorization for Rich Internet Applications (Applets and Web Start). The default security slider is being updated in a way that will block RIAs that do not adhere to these requirements.  Note: this only applies to RIAs, and not to Java on server or desktop applications run outside of a browser.

Summary:

  • You are required to sign all RIAs (Applets and Web Start applications).
  • You are required to set the "Permissions" attribute within the Manifest.
  • Your application will be affected if it uses Java started through a web browser. Your application will not be affected if it runs anywhere outside of a web browser.

Complete information can be found within the Java 7 update 51 release notes (here once 7u51 is released in January 2014).

Developers:

 As of 7u51, (January 14, 2014), your RIAs must be updated. The updates required are on the packaging and distribution; no API code changes should be required. The impetus for these changes relates to potential re-purposing of sandboxed applications, whereby placing permissions within a signed JAR prevents modification of your specified permission level.
RIAs must contain two things:

  1. Code signatures from a trusted authority. All code for Applets and Web Start applications must be signed, regardless of its Permissions attributes.
  2. Manifest Attributes
    1. Permissions – Introduced in 7u25, and required as of 7u51. Indicates if the RIA should run within the sandbox or require full-permissions.
    2. Codebase – Introduced in 7u25 and optional/encouraged as of 7u51. Points to the known location of the hosted code (e.g. intranet.example.com).

Sample META-INF/MANIFEST.MF file:

Manifest-Version: 1.0
Created-By: 1.7.0_51
Permissions: sandbox
Codebase: www.java.com java.com

This manifest file is created when the JAR is packaged, either through the default jar command, your build tool, or your IDE.

Sample JNLP for launching a web start application:

<?xml version="1.0" encoding="UTF-8"?>
<jnlp href="JavaDetection_applet.jnlp">
    <information>
        <title>Java Detection</title>
        <vendor>Oracle Inc.</vendor>
    </information>
    <resources>
        <jar href="JavaDetection.jar" />
    </resources>
    <applet-desc
          name="Java Detection Applet"
         main-class="JavaDetection"
         width="1"
         height="1">
     </applet-desc>
     <update check="background"/>
</jnlp>

Some developers may notice that the <security /> element is missing from the above JNLP. By providing it within the cryptographically signed JAR file, it is no longer necessary within the JNLP for Java 7 update 51 (January 2014).

See the Development and Deployment Of Rich Internet Applications for full details of JNLPs and the deployment toolkit. For instructions on signing code, see the tutorial Lesson: Signing Code and Granting It Permissions.

Desktop Administrators

If you are a desktop administrator managing Java installations across a series of computers, consider using Deployment Rule Sets to whitelist your internal applications. Deployment Rule Sets allow you to certify that an application is known to be trusted and safe, even if you cannot update the application to adhere to these requirements.

Tuesday Sep 03, 2013

Code signing: Understanding who and when

Code signatures have become more commonplace for applications in recent years and especially so in Java 7 update 21 (April 16, 2013). The security notifications for Java help provide your users with an understanding of who wrote the application so that they can decide whether to run it or not. Through the default settings of the Java security slider, end-users are blocked from running unsigned or self-signed applets and prompted for running signed applets.

These cryptographic signatures are designed to provide a means of authentication, proving to users that they are indeed running the same application that you wrote and that it has not been modified in any way. Within information security threat modeling terms, this is a means of repudiation.

Developers must sign any browser applet or Web Start application that they produce. Signatures on other application types (such as back-end server applications) are optional.

System Administrators may be impacted and have a choice for what to do:

  1. For managed users, the system administrator can add a Deployment Rule Set to client systems and indicate which applets may run.
  2. For unmanaged or bring-your-own-device users, the system administrator may sign jars with their own certificate.

Several steps are involved to sign code:

  1. Determine who in your organization is responsible for code signing
  2. Purchase a signing certificate from a public Certificate Authority.
  3. System Administrators: sign a jar using normal commands
  4. Developers: integrate code signing into your build chain

Determine who in your organization is responsible for code signing

In corporate enterprises, there is often a technology group responsible for these signatures. This group is usually separate from most system administrators in order to keep the private key a secret. The goal is to decrease the number of people with access to the private key.

If you are in a corporate enterprise, please look internally for a code signing group and ask them for their signing process instead.

Purchase a signing certificate

If you or your group is identified as responsible for code signing, then the next step is to obtain a code signing certificate. If a different group provides signatures (as in many large organizations), follow their process instead.

All users (system administrators and developers) that intend to sign code must purchase a signing certificate from a known authority. Certificate authorities help manage trust across millions of systems and prevent identity spoofing, or cases where someone else generates their own certificate pretending to be you. Signing certificates are available from companies like GoDaddy, Symantec, or others. Each certificate authority provides instructions for generating a certificate signing request with the keytool command.

Code signing certificates are different from domain certificates normally used for HTTPS websites. Signing certificates must be purchased from a Certificate Authority -- Oracle is not a Certificate Authority.

System Administrators: sign a jar using normal commands

After receiving the signing certificate, system administrators can sign files using the following jarsigner command:

jarsigner -verbose -keystore "c:\Users\ecostlow\javakeystore_keepsecret.jks" -tsa http://timestamp.verisign.com -signedjar FILENAME.jar FILENAME.jar your-certificate-name
Enter Passphrase for keystore:
 updating: META-INF/MANIFEST.MF
   adding: META-INF/COSTLOW.SF
   adding: META-INF/COSTLOW.RSA
  signing: ruleset.xml

Developers: integrate code signing into your build chain

In an ideal environment, members of the development team would not have access to the private key and its password. The fewer people that have this private key, the better.

For build automation, you can create stubs that allow other members of the team to substitute the real private key and password, without exposing this sensitive information.

Please note that Oracle only maintains the default jarsigner command (described above for System Administrators) and does not manage or control build tools.

Ant

The ant build system provides a SignJar task to mimic the jarsigner command. When using this task, just be sure to call the ant sign target.

<property file="devAndBuildHaveDifferentValues.properties" />
<target name="sign">
	<signjar
		alias="${sign.alias}" keystore="${sign.keystore}"
		storepass="${sign.storepass}" tsaurl="http://timestamp.verisign.com">
	  <path>
		<fileset dir="dist" includes="**/*.jar" />
	  </path>
	</signjar>
</target>

Then, both the development team and build team would have different entries for devAndBuildHaveDifferentValues.properties

 Dev would have this for testing
Build (continuous integration) would have this, keeping it secret
sign.alias=mykey
sign.keystore=testcerts.jks
sign.storepass=changeit
sign.alias=mykey
sign.keystore=/build/keepSecretFromEveryone.jks
sign.storepass=N0bodyE1se5houldKnowThis

By taking these actions, developers can automate their build to sign jar files without exposing the private key to the entire development team.

Maven

Maven provides a maven-jarsigner plugin to mimic the jarsigner command.

<build>
	<plugins>
		...
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-jarsigner-plugin</artifactId>
			<version>1.2</version>
			<executions>
				<execution>
					<id>sign</id>
					<goals>
						<goal>sign</goal>
					</goals>
				</execution>
			</executions>
			<configuration>
				<keystore>${sign.keystore}</keystore>
				<alias>${sign.alias}</alias>
				<storepass>${sign.storepass}</storepass>
			</configuration>
		</plugin>
		...
	</plugins>
</build>

Maven uses the idea of Profiles to externalize properties.

Dev would have this for testing
Build (continuous integration) would have this, keeping it secret
sign.alias=mykey
sign.keystore=testcerts.jks
sign.storepass=changeit
sign.alias=mykey
sign.keystore=c:/build/keepSecretFromEveryone.jks
sign.storepass=N0bodyE1se5houldKnowThis

By taking these actions, developers can automate their build to sign jar files without exposing the private key to the entire development team.

Other build system

If your development team is using an alternate build system, please review its documentation for the appropriate call. Most build systems should have this, but the default jarsigner command will always work if you need.

Leveraging internal code signing authorities

Many large organizations have an internal code signing group. The benefit of these groups is that they help keep the private keys secret in a way that neither developers nor build integrators have access. Separation also allows this group to dedicate more time towards best practices, like keeping keys on tamper-proof hardware/smart-cards. If your organization has this group, the usual practice is to automate sending code artifacts to this team’s service and retrieving the resulting signed artifacts. Reference documentation for using separate hardware key components is available in the PKCS#11 Reference Guide.

A word on timestamps

The optional timestamping provides a notary-like capability of identifying when the signature was applied. This is helpful if your private key is compromised at any point. If a jar was signed before the key was thought to be compromised, the signature is still valid even through the certificate may be revoked. Certificate Authorities should allow back-dating of revocations in case the loss is not noticed right away. If a certificate is revoked and the signed jar is:

  • Timestamped before the stated date of compromise: then the signature is valid because the owner still had sole possession.
  • Timestamped on or after the stated date of compromise: the signature is not valid. Whoever else had the certificate could have faked this.
  • Not timestamped: the signature is not valid. We have no way of knowing when the jar was signed and assume it was after the compromise.

Although not required, it is a good practice to timestamp anything that you sign. Popular timestamping authority URLs include:

  • http://timestamp.verisign.com
  • http://tsa.starfieldtech.com
  • https://timestamp.geotrust.com/tsa
About

Science Duke
This blog contains topics related to Java SE, Java Security and Usability. The target audience is developers, sysadmins and architects that build, deploy and manage Java applications. Contributions come from the Java SE Product Management team.

Search

Categories
Archives
« September 2013 »
SunMonTueWedThuFriSat
1
2
4
5
6
7
8
10
11
12
13
14
15
16
18
19
20
21
22
23
24
25
26
27
28
29
30
     
       
Today