United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 4532506 Serializing KeyPair on one VM (Sun) then Deserializing on another (IBM) fails
4532506 : Serializing KeyPair on one VM (Sun) then Deserializing on another (IBM) fails

Details
Type:
Bug
Submit Date:
2001-11-28
Status:
Resolved
Updated Date:
2007-03-20
Project Name:
JDK
Resolved Date:
2003-09-11
Component:
security-libs
OS:
generic,windows_xp
Sub-Component:
java.security
CPU:
x86,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.3.1,6
Fixed Versions:
5.0

Related Reports
Duplicate:
JDK-6536046 - Serialization and javax.security interface classes (e.g. PublicKey)
Relates:
JDK-4833034 - Obfuscation is changing variable names for serialization

Sub Tasks

Description

Name: jl125535			Date: 11/28/2001


java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.1-FCS)
Java HotSpot(TM) Client VM (build Blackdown-1.3.1-FCS, mixed mode)



I have a service based application which downloads code to access the application 
remotely. If the client VM is say IBM but the VM which runs the application is Sun then 
I cannot send a KeyPair (or any object which contains PublicKey,PrivateKey) down a 
socket using Serialization.

Because KeyPair uses the default serialization then when it comes to serialize the 
public and private components of the pair (which are only interfaces PublicKey & PrivateKey) 
then the real objects are serialized. On a Sun VM this is com.sun.xxx but on an IBM this 
is com.ibm.xxx.

If the application uses some rpc type communication then any remote interfaces 
cannot contain any methods which contains these objects in their declaration:

public void verify(PublicKey key) - could not be an rpc method.


There is a work around (described later) but this still means the rpc method has to 
change and really if I use something in any java. packages then I should really expect 
this to work on other VMs (Write once run anywhere?) and I thought this may of been 
the reason for the provider pattern in the security architecture.


public void verify(ManuallyEncodedPublicKey key)

    - manually serializes the key using X.509EncodedKeySpec

This has impact on any serialization of these classes accross multiple providers.
(Review ID: 135083) 
======================================================================

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger
tiger-b20
2004-06-14 
WORK AROUND



Name: jl125535			Date: 11/28/2001


CUSTOMER WORKAROUND:

This means any distributed application which uses the java.security.PublicKey and 
java.security.PrivateKey has to serialize the keys manually using some encoding like 
X.509 and PCKS#8 to ensure that whatever provider is set for the security keys 
doesn't store the private & public keys as the implementation objects.
======================================================================
2004-06-11 
EVALUATION

1.  new public serialized key representation:

    public class java.security.KeyRep {
        public KeyRep(String type,  // "PublicKey|PrivateKey|SecretKey"
                  String algorithm,
                  String encoding, // "X509|PKCS8|RAW"
                  byte[] encoded) { }

        protected Object readResolve() throws ObjectStreamException {
            // use KeyFactory to create key
        }
    }

2   modify PublicKey/PrivateKey/SecretKey javadocs to state (respectively):

    A PublicKey should use KeyRep as its serialized form.
    (don't say anything about encodings - anything is fine)

our provider Key classes would writeReplace KeyRep,
but also implement readObject so it can deserialize
pre-1.5 keys if it gets one (if KeyRep is received,
KeyRep's readResolve is used).
2004-06-11


Hardware and Software, Engineered to Work Together