Page History

Java uses code signing as a requirement for granting elevated privileges to code. Many security policies permit signed code to operate with privileges that exceed the defaultprivileges given to unsigned code. For example, Java applets can escape the default sandbox restrictions when signed. Applications can use custom security policies based on code signing. Consequently, users can grant explicit permissions either to a particular codebase code base or to all code signed by a particular signer. This approach places control of security in the hands of the user, who can choose whether to run an application with full or restricted permissions.

...

Code signing is designed to authenticate the origin of the code, as well as to verify the integrity of the code. It relies on a Certification Authority certification authority (CA) to confirm the identity of the principal signer. Naive users should not be expected to understand how certificates and the Public Key Infrastructure public key infrastructure (PKI) work.

Users commonly associate digital signatures with safety of code execution, trusting the code to cause them no harm. The problem arises when a vulnerability is discovered in signed code. Because many systems are configured to permanently trust certain signing organizations, those systems fail to notify their users when downloading content signed by the trusted organization, even when that content contains vulnerabilities. An attacker can offer the users legitimately signed vulnerable content with the intention of exploiting that content.

...

An organization that signs its own code should not vouch for code acquired from a third party without carefully auditing the third-party code. When signing privileged code, ensure that all of the signed code is confined to a single jar file (as in rule ENV01-J. Place all security-sensitive code in a single jar and sign and seal it for more information), and also that any code invoked from the privileged code is also contained in that jar file. Non-privileged code must be left unsigned, restricting it to the sandbox. For instanceexample, unsigned applets and JNLP applications are granted the minimum set of privileges and are restricted to the sandbox. Finally, never sign any code that is incomprehensible or unaudited.

...

ENV00-EX1: An organization that has an internal PKI and uses code signing for internal development activities (such as facilitating code check-in and tracking developer activity) may sign unprivileged code. This codebase code base should not be carried forward to the production environment. The keys used for internal signing must be distinct from those used to sign externally available code.

...

...

...