Java Secures Supply Chains through Code Signing
This post was originally published by Bruce Morton & Erik Costlow on the CA Security Council blog.
We have recently discussed the benefits of code signing in two posts: Securing Software Distribution with Digital Signatures and Improving Code Signing. These posts covered the role of code signatures as a “digital shrinkwrap” designed to answer a simple question: Did the software I am about to run actually come from the author or has someone changed it along the way?
As software is downloaded, assembled, copied, distributed and redistributed, it can be modified at any point along the supply chain. Some modifications are designed to insert advertising into software, others add tracking capabilities, and others could be more nefarious, such as compromising the entire host or stealing data.
Cryptographic code signatures are not designed to protect against piracy, rather they are for authenticity; to prove that software came from its author and has not been altered.
Code signatures protect all parties from this threat. End-users can validate the signature to determine that it came from the publisher and was not modified by anyone along the way. Similarly, the publisher can mathematically prove that their code was not modified as it went through the supply chain, such as by a reseller or the actual customer. In September 2013, Oracle announced that Java 7 update 51 (January 2014) will require valid code signatures for Applet & Web Start applications. This is a positive step for security overall as it:
- Allows end-users to run applications from publishers they trust
- Protects end-users from applications where identity cannot be verified
- Ensures indications where legitimate applications have been tampered with (i.e., tampering would break the signature).
Oracle has also made improvements in Java’s code signatures, such as separating the role of identity and permissions. In the past, signed applets affected the level of permissions to determine what an applet could do: unsigned applets ran in a sandbox and signed applets were granted all-permissions. As of Java 7 update 21 (April 2013), Oracle separated the role of identity and authorization to allow signing of sandboxed code. By doing this, software publishers can use the same cryptographic signatures of sandbox applications used to protect high-privileged ones.
The expanding importance of code signatures also pertains to software assembly and defends against attacks like Cross-Build Injection. As applications have grown to involve more third-party, open-source or commercial components, there is concern to ensure that the binary artifacts that run are the same as what the publisher provided. While the Java changes discussed previously focus on protecting both end-users and developers of Applet & Web Start applications, the code-signing techniques can also be applied for back-end and server-side applications.
Given the popularity of the Java platform and its role behind many applications, this large-scale use of code signatures is significant for the future of Public Key Infrastructure and trusted identity.