With the new JCE 1.2.1, customizing securitymanager may be necessary in order to properly implement your provider. Sun also asks that providers carefully document services for users, and although JCE 1.2.1 hallmarks availability of these cryptography tools outside of the United States, implementing them in this way adds a layer of complexity.
Your provider may need permissions from securitymanager in order to run.
java.io.FilePermission is needed when authenticating JCE 1.2.1,
java.lang.RuntimePermission is needed for a provider to get its own protection domain, and
java.security.SecurityPermisions are necessary to set provider properties. These permissions are necessary when the JCE 1.2.1 framework is not an installed extension or when a client does not install your provider as an installed extension.
The types of algorithms and other services implemented by your provider and instructions for installation need to be included as part of your provider documentation, especially if you plan on selling or sharing your provider online. This should at least include the name programs should use to refer to your provider, which is currently case sensitive.
Sun also recommends documentation specifics for different kinds of services: Message digests and MAC algorithms should state whether they are or are not cloneable. Signature algorithms should have documentation on the format in which the signature is encoded. Random-number generators should include information on the quality of the seed and randomness. Key-pair generators should list which key specification is supported. Key factories should list what types of keys can be created with the generator. Algorithm parameter generators should provide the default initialization. For more information and specifics on documenting your provider, please see Sun’s article “How to Implement a Provider for the JCE.”
Outside of the United States
Outside of the United States and Canada, CipherSpi implementations must include an implementation of JCE 1.2.1’s
engineGetKeySize method, which returns the key size. This method compares the result with the maximum allowable key size for a specific location and throws an exception if the encryption is too large. This is a form of authenticating the provider and must be signed by a trusted entity. The JCE 1.2.1 framework is digitally signed, and currently there are two trusted Certification Authorities, Sun Microsystems’ JCE Code Signing CA, and IBM’s JCE Code Signing CA.
Vendors outside of the United States or Canada need to apply to the Bureau of Export Administration in the U.S. Department of Commerce for export approval. The vendor then needs to get a code-signing certificate for testing, which they can get by sending a CSR and contact info to Sun (again see “How to Implement a Provider for the JCE” for more information). Vendors outside of the United States or Canada should check with Sun’s official site, the Bureau of Export Administration, the United States Department of Commerce, their local government offices, and seek legal counsel before distributing a provider.
After Sun provides a vendor with a testing code certificate, they can test just like any other provider for up to 30 days. After testing, the vendor can then receive a production code certificate using the same process. For outside vendors, Sun recommends that the constructor of each SPI implementation class authenticates JCE 1.2.1, that the constructor of each SPI class does self-integrity checking, and that the provider code is written so that provider classes become unusable if bypassing JCE 1.2.1.
References and Resources
- JCE Overview
- How to Implement a Provider for the JCE
- Inside Java 2 Platform Security, Li Gong, Addison Wesley, 1999
- Java Cryptology, Jonathon Knudsen, O’Reilly and Associates, 1998
- Java Security Handbook, Jamie Jaworski and Paul Perrone, SAMS Publishing, 2000
- The U.S. Department of Commerce
- The Bureau of Export Administration
About the Author
Thomas Gutschmidt is a freelance writer, in Bellevue, Wash., who also works for Widevine Technologies.