Tuesday, April 26, 2005
More about my experience in PSEMembership
I am resuming today the blog I was writing yesterday about my experience the JXTA's PSEMembership
Comment 4:
In the PSEMembershipService class, the "join (Authenticator authenticator)" method (see code snipplet below) not only makes sure that the Authenticator provided is "completed correctly" (isReadyForJoin() method), :
but also that the but also that the Authenticator passed to the PSEMembershipService is the same as the one that was provided initially:
However since the Membership class to be used in a given peergroup is only described by it class name in the Module Impl Adv
(See XML Element extracted from Membership Module Impl Advertisement below)
This would allow my local rogue peer to join a PSEMembership managed peer group.
http://www.jxta.org/download/jxta.jar file could be signed, preventing tempering, but my experience is that you can "custom" the jxta.jar file without any consequences. So should be signed, the code does not check for tempering.
Comment 5:
I used a PSEConfigAdv instance to put together the Peer Group Advertisement parameters needed for the PSE Membership. It works well if you specify only the following PSEConfigAdv Parameter the Certificate Chain or Certficate ; e.g:
pseConfigAdv.setPrivateKey(nodeGroupPrivateKey,saxtaGroupPSEMembershipPassword);
Now should you provide other parameters such as the "KeyStore Type" and "KeyStoreProvider" the Peer Group advertisement would look like:
...
The 2 added attributes will actually make the JXTA throw and exception:
Comment 6:
Below is the valid PSEConfig Advertisement part of the Saxta Peer Group. This PSEConfig Advertisement what created with the following commands:
Note that what was passed to the pseConfigAdvertisement was a CertificateChain (an Array of certificates) containing the Certificate Authority's X509Certificate (at index 1) as well as the signed PeerGroup X509Certificate (index 0).
The correspond advertisement Element is as followed:
<Svc>
<MCID>
urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE0000000505
</MCID>
<Parm type="jxta:PSEConfig" xmlns:jxta="http://jxta.org">
<RootCert>
<Certificate>
MIICJjCCAY+gAwIBAgIBATANBgkqhkiG9w0BAQUFADBJMRUwEwYDVQQKEwx3d3cuanh0YS5vcmcx
ETAPBgNVBAMTCFNheHRhLUNBMR0wGwYDVQQLExRFQzgwREE5RDdCNkI4Mjk1MkU2NjAeFw0wNTA0
MDQxOTAxMTJaFw0wNTA4MDIxOTAxMTJaMGkxFTATBgNVBAoTDHd3dy5qeHRhLm9yZzExMC8GA1UE
AxMoVU1EIFNheHRhQ29tbXVuaXR5IE5vZGUgR3JvdXAgTWFuYWdlci1DQTEdMBsGA1UECxMUNTBD
OUIyRDg3Rjk4NzhGNkI3ODIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKJS038q+gmKGjff
kv22pt8AuMIzqkU5ciofp0ZgavgNSLBmCwbuEq+Z2LvguBMU2zzHlVGH2xBjjFs9ZaO5chEqztyd
X4lrGj6r1aiY07JhTrKehQ/sIzk4ZK7KZ7ZvzAQECcIfuz/leBVeRh0pVGtvXRr8f8Km393cuPb2
vqRHAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEALZPcRiYf4BBaZYBn0oltKNWiHKgSgHcxnWUL2S+K
hrGpjeDXbUH9MbUPPrMZ39EjsIL/qU8lTt05SDMK05Y18JdX3lXQZ1Q+E9hm/MB8pFHYX8AGLCMh
YwmnjCUV0uv/oxwOR7+a2v+JKL+GoGT/C/OHQ2rJfDJ/pwoZVNd7CbM=
</Certificate>
<EncryptedPrivateKey algorithm="RSA">
MIICoTAbBgkqhkiG9w0BBQMwDgQI8XQZohplhAECAgH0BIICgGiECYe6x10txBR7Zf6vHsG5O5q1
8+4OO4ns7f0RpYPqHGYW6snPZrg4DoZ2lbZajGz5xXaboS0W+EzGWzFFTzSL4RfTjvQIx7+uyWV8
In9CLO0Spq2AdQV1tqAEB1lPmCe/sAuFZGeVQzaJrmut2ibyNZvGSLFjQXJ1rs/8jgOUmerK/JMg
5ksIwm0TsNMiEDbE+CAwhWfdgqHbBA+dmqV+E7KWJrbhMMqnUM6a6m42b5ZoMjDQlpC95fsZtpE6
gMY1oTOubYPHgs+p9cSDe+pcQDV19+mjXPqsbVtqWrPezn1+xMpj2INLM2STnemVXD4CQb4c+tXc
viRNlYr1gyQQ/A262wPx3kI9sh7HXN2ZBO2xrlWCBxf8/AedoMpba0bw/Y6LkxcSvCEDTM4WtVFT
d2Dh4W3jqRt62rXqpq+vzjLL0aemQygBUku/WAUHn+qk7HRTJamRdiOPYKd4ZDxkyMedXlkwIocQ
d35yfQ5fvNbOe0PLkRXnjid7Af2S7XNfs8eTZSCXhzxV1wuEH6jRiMgW9uzpp2EJjdugrboe8gty
C00HoP0U02usUVKqoJtMS0dX/PJHbIMLXvXPqJnZ+3TKpWpxxNC2I3qurhw2k4RH6LGSqK6Qsc3Q
HSQBvoJxNaN0AG60916giLwSIRJIgKIAtyxNvhuBkZuEHN5po1bT62zQ2tGQjU0/cLvuJ/6eH6Jz
G17L1tRSWmjtLLMIdbQ90iqBMJQf0YSs5hJ8UJGW6ST3aMnOP9Rf0Ge+QK1GRjuGoI0KEo9xSom6
iUqEIzutFQYiCCm3P2M/R/FQZd0KsigsaiIA0YnHNy3pZKrrzZOsoSczyhyIGnHX/gA=
</EncryptedPrivateKey>
</RootCert>
</Parm>
</Svc>
The certificate chain has been truncated to the Peer Group X509Certificate (the CA X509 Certificate has been discarded), which confirms the comments in the JXTA code that the PSE Membership does not support certificate chains.
It actually is an issue for me as I rely on a "self signed" certificate authority to identify potential rogue/unauthorized super peers: Valid Super Peers have their Certificates signed by the CA.
Comment 4:
In the PSEMembershipService class, the "join (Authenticator authenticator)" method (see code snipplet below) not only makes sure that the Authenticator provided is "completed correctly" (isReadyForJoin() method), :
public Credential join( Authenticator authenticated ) throws PeerGroupException {
if( this != authenticated.getSourceService() ) {
throw new ClassCastException( "This is not my authenticator!" );
}
if( !authenticated.isReadyForJoin() ) {
throw new PeerGroupException( "Authenticator not ready to join!" );
}
but also that the but also that the Authenticator passed to the PSEMembershipService is the same as the one that was provided initially:
if( this != authenticated.getSourceService() ) {Such may prevent "Authenticator" spoofing to some extent.
throw new ClassCastException( "This is not my authenticator!" );
}
However since the Membership class to be used in a given peergroup is only described by it class name in the Module Impl Adv
(See XML Element extracted from Membership Module Impl Advertisement below)
Nothing prevents me to write a rogue net.jxta.impl.membership.pse.PSEMembershipService Class, and replacing the orginal one with the rogue one on my local peer.
<svc>
<jxta:mia jxta="http://jxta.org">
<msid>
urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE000000050306
</msid>
<comp>
<efmt>
JDK1.4.1
</efmt>
<bind>
V2.0 Ref Impl
</bind>
</comp>
<code>
net.jxta.impl.membership.pse.PSEMembershipService
</code>
<puri>
http://www.jxta.org/download/jxta.jar
</puri>
<prov>
sun.com
</prov>
<desc>
Module Impl Advertisement for the Certificate Based Services
</desc>
</jxta:mia>
</svc>
This would allow my local rogue peer to join a PSEMembership managed peer group.
http://www.jxta.org/download/jxta.jar file could be signed, preventing tempering, but my experience is that you can "custom" the jxta.jar file without any consequences. So should be signed, the code does not check for tempering.
Comment 5:
I used a PSEConfigAdv instance to put together the Peer Group Advertisement parameters needed for the PSE Membership. It works well if you specify only the following PSEConfigAdv Parameter the Certificate Chain or Certficate ; e.g:
pseConfigAdv.setCertificateChain(x509CertificateChain);and the Private Key; e.g:
pseConfigAdv.setPrivateKey(nodeGroupPrivateKey,saxtaGroupPSEMembershipPassword);
Now should you provide other parameters such as the "KeyStore Type" and "KeyStoreProvider" the Peer Group advertisement would look like:
...
<svc>...
<mcid>
urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE0000000505
</mcid>
<parm type="jxta:PSEConfig" jxta="http://jxta.org" keystoretype="jks" keystoreprovider="SUN version 1.5">
<rootcert>
<certificate>
The 2 added attributes will actually make the JXTA throw and exception:
Exception in thread "main" java.lang.reflect.UndeclaredThrowableExceptionThis error took me a [very] long time to find out as the error message make you think that the ModuleImplementation Advertisement is the problematic one, not the peer group advertisement.
at net.jxta.impl.peergroup.GenericPeerGroup.loadModule(GenericPeerGroup.java:818)
at net.jxta.impl.peergroup.GenericPeerGroup.newGroup(GenericPeerGroup.java:1304)
at net.jxta.impl.peergroup.PeerGroupInterface.newGroup(PeerGroupInterface.java:290)
Comment 6:
Below is the valid PSEConfig Advertisement part of the Saxta Peer Group. This PSEConfig Advertisement what created with the following commands:
PSEConfigAdv pseConfigAdv = (PSEConfigAdv) AdvertisementFactory.newAdvertisement(PSEConfigAdv.getAdvertisementType());
pseConfigAdv.setPrivateKey(nodeGroupPrivateKey,saxtaGroupPSEMembershipPassword) ;
pseConfigAdv.setCertificateChain(x509CertificateChain);
Note that what was passed to the pseConfigAdvertisement was a CertificateChain (an Array of certificates) containing the Certificate Authority's X509Certificate (at index 1) as well as the signed PeerGroup X509Certificate (index 0).
The correspond advertisement Element is as followed:
<Svc>
<MCID>
urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE0000000505
</MCID>
<Parm type="jxta:PSEConfig" xmlns:jxta="http://jxta.org">
<RootCert>
<Certificate>
MIICJjCCAY+gAwIBAgIBATANBgkqhkiG9w0BAQUFADBJMRUwEwYDVQQKEwx3d3cuanh0YS5vcmcx
ETAPBgNVBAMTCFNheHRhLUNBMR0wGwYDVQQLExRFQzgwREE5RDdCNkI4Mjk1MkU2NjAeFw0wNTA0
MDQxOTAxMTJaFw0wNTA4MDIxOTAxMTJaMGkxFTATBgNVBAoTDHd3dy5qeHRhLm9yZzExMC8GA1UE
AxMoVU1EIFNheHRhQ29tbXVuaXR5IE5vZGUgR3JvdXAgTWFuYWdlci1DQTEdMBsGA1UECxMUNTBD
OUIyRDg3Rjk4NzhGNkI3ODIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKJS038q+gmKGjff
kv22pt8AuMIzqkU5ciofp0ZgavgNSLBmCwbuEq+Z2LvguBMU2zzHlVGH2xBjjFs9ZaO5chEqztyd
X4lrGj6r1aiY07JhTrKehQ/sIzk4ZK7KZ7ZvzAQECcIfuz/leBVeRh0pVGtvXRr8f8Km393cuPb2
vqRHAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEALZPcRiYf4BBaZYBn0oltKNWiHKgSgHcxnWUL2S+K
hrGpjeDXbUH9MbUPPrMZ39EjsIL/qU8lTt05SDMK05Y18JdX3lXQZ1Q+E9hm/MB8pFHYX8AGLCMh
YwmnjCUV0uv/oxwOR7+a2v+JKL+GoGT/C/OHQ2rJfDJ/pwoZVNd7CbM=
</Certificate>
<EncryptedPrivateKey algorithm="RSA">
MIICoTAbBgkqhkiG9w0BBQMwDgQI8XQZohplhAECAgH0BIICgGiECYe6x10txBR7Zf6vHsG5O5q1
8+4OO4ns7f0RpYPqHGYW6snPZrg4DoZ2lbZajGz5xXaboS0W+EzGWzFFTzSL4RfTjvQIx7+uyWV8
In9CLO0Spq2AdQV1tqAEB1lPmCe/sAuFZGeVQzaJrmut2ibyNZvGSLFjQXJ1rs/8jgOUmerK/JMg
5ksIwm0TsNMiEDbE+CAwhWfdgqHbBA+dmqV+E7KWJrbhMMqnUM6a6m42b5ZoMjDQlpC95fsZtpE6
gMY1oTOubYPHgs+p9cSDe+pcQDV19+mjXPqsbVtqWrPezn1+xMpj2INLM2STnemVXD4CQb4c+tXc
viRNlYr1gyQQ/A262wPx3kI9sh7HXN2ZBO2xrlWCBxf8/AedoMpba0bw/Y6LkxcSvCEDTM4WtVFT
d2Dh4W3jqRt62rXqpq+vzjLL0aemQygBUku/WAUHn+qk7HRTJamRdiOPYKd4ZDxkyMedXlkwIocQ
d35yfQ5fvNbOe0PLkRXnjid7Af2S7XNfs8eTZSCXhzxV1wuEH6jRiMgW9uzpp2EJjdugrboe8gty
C00HoP0U02usUVKqoJtMS0dX/PJHbIMLXvXPqJnZ+3TKpWpxxNC2I3qurhw2k4RH6LGSqK6Qsc3Q
HSQBvoJxNaN0AG60916giLwSIRJIgKIAtyxNvhuBkZuEHN5po1bT62zQ2tGQjU0/cLvuJ/6eH6Jz
G17L1tRSWmjtLLMIdbQ90iqBMJQf0YSs5hJ8UJGW6ST3aMnOP9Rf0Ge+QK1GRjuGoI0KEo9xSom6
iUqEIzutFQYiCCm3P2M/R/FQZd0KsigsaiIA0YnHNy3pZKrrzZOsoSczyhyIGnHX/gA=
</EncryptedPrivateKey>
</RootCert>
</Parm>
</Svc>
The certificate chain has been truncated to the Peer Group X509Certificate (the CA X509 Certificate has been discarded), which confirms the comments in the JXTA code that the PSE Membership does not support certificate chains.
It actually is an issue for me as I rely on a "self signed" certificate authority to identify potential rogue/unauthorized super peers: Valid Super Peers have their Certificates signed by the CA.
# posted by Happy Geek @ 9:36 AM 
Comments:
<< Home
Comment 4:
The ClassCastException is not intended to be a security mechanism.
The problem is that JXTA doesn't allow a change to the method prototype in the derived version. So casting of the Authenticator object is required within all implementations to make sure thate the Authenticator object passed in is theirs. The check and ClassCastException is intended to be a "friendlier" version of the class cast exception that would occur when PSE attempted to cast the Authenticator instance to a PSEAuthenticator.
(The default ClassCastException doesn't bother to identify the desired class nor failing the class provided).
Comment 5:
I'd like to better understand this problem. I've successfully used those paratemeters to use PKCS#12 keystore and they are used by Nick Betteridge's PSE SmartCard extensions. What exactly was failing?
Comment 6: Certificate chains should be support in the case you state. The restriction on certificate chains was relaxed in JXTA 2.3 wherein a single chain of certificates can now be imported with the initial public key. Only a single chain is still allowed though so It's not quite as complete as some might wish.
Post a Comment
The ClassCastException is not intended to be a security mechanism.
The problem is that JXTA doesn't allow a change to the method prototype in the derived version. So casting of the Authenticator object is required within all implementations to make sure thate the Authenticator object passed in is theirs. The check and ClassCastException is intended to be a "friendlier" version of the class cast exception that would occur when PSE attempted to cast the Authenticator instance to a PSEAuthenticator.
(The default ClassCastException doesn't bother to identify the desired class nor failing the class provided).
Comment 5:
I'd like to better understand this problem. I've successfully used those paratemeters to use PKCS#12 keystore and they are used by Nick Betteridge's PSE SmartCard extensions. What exactly was failing?
Comment 6: Certificate chains should be support in the case you state. The restriction on certificate chains was relaxed in JXTA 2.3 wherein a single chain of certificates can now be imported with the initial public key. Only a single chain is still allowed though so It's not quite as complete as some might wish.
<< Home
