[sip-comm-dev] ZRTP integration (possible) OSGi bundle related problem and current general status


#1

Hello all,

I'll copy-paste pretty much from my last dev blog entry made some minutes ago, starting after a short paranthesis with the problem I'm currently facing, for which any feedback will be welcome.

(To Werner: the current sources are available on a SC svn branch at https://sip-communicator.dev.java.net/svn/sip-communicator/branches/encryption/
; please let me know if you have any problems accessing them - you'll probably need a java.net account in case you don't already have one ; for a very short description of a few modifications done last weekend check the final part of the mail or my dev blog)

Probably the best way to start explain the problem it is actually pasting the exception I get:

----------- #1 ----------
[java] java.lang.SecurityException: JCE cannot authenticate the provider BC

···

-----------
[java] at javax.crypto.SunJCE_b.a(DashoA13*..)
[java] at javax.crypto.Mac.getInstance(DashoA13*..)
[java] at gnu.java.zrtp.ZRtp.(ZRtp.java:325)
[java] at net.java.sip.communicator.impl.media.transform.zrtp.ZRTPTransformEngine.initialize(ZRTPTransformEngine.java:641)
[java] at net.java.sip.communicator.impl.media.CallSessionImpl.initializeRtpManager(CallSessionImpl.java:1578)
[java] at net.java.sip.communicator.impl.media.CallSessionImpl.allocateMediaPorts(CallSessionImpl.java:1519)
[java] at net.java.sip.communicator.impl.media.CallSessionImpl.createSessionDescription(CallSessionImpl.java:989)
[java] at net.java.sip.communicator.impl.media.CallSessionImpl.createSdpOffer(CallSessionImpl.java:573)
[java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.createOutgoingCall(OperationSetBasicTelephonySipImpl.java:257)
[java] at net.java.sip.communicator.impl.protocol.sip.OperationSetBasicTelephonySipImpl.createCall(OperationSetBasicTelephonySipImpl.java:116)
[java] at net.java.sip.communicator.impl.gui.main.call.CallManager$CreateCallThread.run(CallManager.java:833)
----------- #2 ----------
[java] Caused by: java.util.jar.JarException: Cannot parse reference:file:sc-bundles/media.jar
-----------
[java] at javax.crypto.SunJCE_c.a(DashoA13*..)
[java] at javax.crypto.SunJCE_b.b(DashoA13*..)
[java] at javax.crypto.SunJCE_b.a(DashoA13*..)
[java] ... 11 more

Ok, the main points of interest, to say so, are the two pointed out exceptions. After some "Google research" done, I've reached a conclusion for the moment (but I'm not very sure about it..). The SecurityException is thrown because the Sun provided implementation of the JCE needs to authenticate any Provider used for cryptography services. According to the bouncycastle site their jar is signed, but... the jar I use at the moment isn't actually the original jar from their site. It is a modified version, made by Su Bing last year, for which I don't know exactly the modifications made. Still, I don't know if the problem resides at the used bouncycastle jar because the exception states it is caused by a jar exception - pointed at #2 - of not being able to parse the media jar. Why is the media jar involved in all these ? Because the contents of the bouncycastle jar were integrated by Su Bing last year at build time through build.xml in the media.jar, which represents the media bundle, in order to be possible to use bouncycastle services. This is related to the OSGi bundle architecture, and was, as far as I can tell after some testing done about a month ago, the reason for the modifications done by Su Bing to the bouncycastle jar = using the original one as it is results in the media bundle failing to start (if I recall corectly). But, as I said before, I'm not sure if the SecurityException thrown is related to these modifications (which again I don't know exactly what about they consist in or how significant they are) or if it is based only on the fact the the bouncycastle code is "embedded" inside the media jar.

Ok, this is the detailed description of the problem. Since Monday I was able to think on some solutions, but I'm not sure any of them will work (or how good they are).

One - quite innapropriate - found after another round of "Google research" can be to use a clean-room JCE implementation which won't try to check at runtime if the bouncycastle provider is authenticated. Like I said I find this quite innapropriate regarding the fact that the bouncycastle jar is signed and in theory there shouldn't be a problem related to the authentication. Besides that, I've looked a bit for some clean room JCE implementations and there aren't many of them (though I didn't do exactly an extensive search - BouncyCastle provides one and I found one more provided by Cryptix). Add to this that I don't know if they're compatible with the current sources (the BouncyCastle one is JDK 1.3 compliant and about the Cryptix one I'm not very sure). Anyway, this approach might be a temporarily solution if nothing else works.

The other solutions focus on eliminating the cause of the problem, rather than effect, about which cause I'm not sure what actually is it, as stated above, in the problem description. So, one option, would be to try separate the bouncycastle jar from the media jar and to import it as an external source, which I don't know if it's possible. If I recall correctly there is a Bundle-Classpath parameter available for the OSGi bundle manifest, but at this very moment when I'm writing I'm not sure if it could be of some use for this. I'll do a bit of research to find out, but any feedback from someone experienced with the OSGi architecture for this and actually for a possible solution for the whole matter should be very helpful.

Another solution, which again I don't know it will solve the problem is to try using the original bouncycastle jar. For this I should try using it again, compare the logs and the behavior, and see if I can't figure out what is the problem exactly. If this won't be enough (and according to last time attempt, might not be..) I'll probably should unpack the modified one and look at the differences (there is a small problem here - the modified one is version 1.37 and the bouncycastle provided one reached version 1.39 meanwhile, and I don't see any web archive with older releases on their site, but maybe I didn't look deep enough.. and anyway a comparison should be possible between different versions too).

This is pretty much what I have in mind at this moment as possible solution. Any feedback about any part of the problem - cause or solution is very welcome.

About other things solved since last week, a quick enumeration available also on the blog will consist in: removing bugs, added Werner's last sources version, finished some refactoring for an almost final source structure and added the current sources on the svn branch.

Regards,
Emanuel

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hey Emanuel,

A quick comment here:

Onica S. Emanuel написа:

So, one option, would be to try
separate the bouncycastle jar from the media jar and to import it as an
external source, which I don't know if it's possible.

You can definitely do this and it's actually something quite common in
SC. You need to add bouncycastle to the project classpath, and then you
also have to add the packages you use to the list that's defined against
the org.osgi.framework.system.packages property in
lib/felix.client.run.properties

Cheers
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Onica S. Emanuel schrieb:
<SNIP - - SNAP>

One - quite innapropriate - found after another round of "Google research" can be to use a clean-room JCE implementation which won't try to check at runtime if the bouncycastle provider is authenticated. Like I said I find this quite innapropriate regarding the fact that the bouncycastle jar is signed and in theory there shouldn't be a problem related to the authentication. Besides that, I've looked a bit for some clean room JCE implementations and there aren't many of them (though I didn't do exactly an extensive search - BouncyCastle provides one and I found one more provided by Cryptix). Add to this that I don't know if they're compatible with the current sources (the BouncyCastle one is JDK 1.3 compliant and about the Cryptix one I'm not very sure). Anyway, this approach might be a temporarily solution if nothing else works.

I'm in favor to use the original BC library, as proposed as an external
jar (Emil already answered that). This way wew can participate with the
ongoing developement of BC or may even change to other JCE providers if
appropriate. Mixing BC into another jar definitely dstroy the security
built into the JCE stuff. I may be able to help with BC (as external jar)
if it fails to load or has other problems - I even have a certificate from
sun that enables me to sign a JCE provider :slight_smile: (some time ago I did a
JCE provider as part of Apache)

The other solutions focus on eliminating the cause of the problem, rather than effect, about which cause I'm not sure what actually is it, as stated above, in the problem description. So, one option, would be to try separate the bouncycastle jar from the media jar and to import it as an external source, which I don't know if it's possible. If I recall correctly there is a Bundle-Classpath parameter available for the OSGi bundle manifest, but at this very moment when I'm writing I'm not sure if it could be of some use for this. I'll do a bit of research to find out, but any feedback from someone experienced with the OSGi architecture for this and actually for a possible solution for the whole matter should be very helpful.

Regards,
Emanuel

Regards,
Werner

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hello all,

I'd like to thank Emil for the useful information, and also Werner for his feedback. Good news, I've just followed the steps described by Emil, and added also a few import lines, and all went fine at a first run. Also, I must mention the old bouncycastle jar problem seems to be solved also, after using it as an external jar = I've used the last (1.39) original unmodified version. (Anyway, I've done only a basic run test prior to this mail without an active peer; I'll continue the debugging and hope all goes fine also from this point forward; I'll commit the modifications to the svn encryption branch after some more debugging to be sure all is ok)

Thanks again,
Emanuel

···

On Wed, 18 Jun 2008, Emil Ivov wrote:

Hey Emanuel,

A quick comment here:

Onica S. Emanuel ������������:

So, one option, would be to try
separate the bouncycastle jar from the media jar and to import it as an
external source, which I don't know if it's possible.

You can definitely do this and it's actually something quite common in
SC. You need to add bouncycastle to the project classpath, and then you
also have to add the packages you use to the list that's defined against
the org.osgi.framework.system.packages property in
lib/felix.client.run.properties

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."