You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Rick McGuire <ri...@gmail.com> on 2005/09/01 19:36:17 UTC
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
I found an interesting example of the inadverent problems that can be
caused by Geronimo's current usage of bouncycastle. The openejb SunOrb
codes specifies a list of supported cipher suites to be used with SSL
connections in the class SSLCipherSuiteDatabase. The supported list
includes the IDEA algorithms. The Sun default JCE implemenation does
not include IDEA, so this will not be used unless additional JCE
provides are installed which include IDEA support. So far, so good.
The IDEA code, even though listed as an option, will not get used
without explicit knowledge of the Gernonmo administrator.
However, the current console code uses the bouncycastle code to
implement its keystore. This usage is in a manner that requires the BC
provider code to be installed programmatically, which the console code
does. Unfortunately, once this is done, the IDEA algorithms are now
available for use for SSL connections as well. This server is now
potentially a royalty collection target by the IDEA patent holders,
since they can demonstrate usage by having a client connect with this
server using the IDEA ciphers. We might even want to consider allowing
these algorithms to be controlled by the server config rather than just
hard coding them in the class.
One way to fix this is just remove the IDEA algorithms from the
SSLCipherSuiteDatabase, so these will not be used for SSL connections.
Another potential solution (yet to be verified) is to use the BC APIs
that allow the default JCE provider to be used for encryption services
rather than defaulting to the BC provider.
Rick
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Rick McGuire <ri...@gmail.com>.
Geir Magnusson Jr. wrote:
> I was talking to Alan and mentioned this. He had another suggestion
> - lets just (for now) get the ASN1 code from BC and package it
> ourselves. Coupled with the suggestion about removing the IDEA
> algorithm as a possibility, we remove the dep on BC in OpenEJB.
I took a crack at stripping down the BC package to just the ASN1 code.
There are two classes that pull in digest code, which pulls in much of
the crypto engine. Thankfully, Geronimo does not depend on those two
classes, and there are no direct references to those classes in the rest
of the ASN1 code, so they can be deleted. Once that is done, it is a
pretty manageable dependency chain, and the code builds just fine. The
resulting package has support for many more datatypes than Geronimo
requires, but I'm not sure a full pruning effort would be justified.
>
> Then, we don't ship BC w/ geronimo, but let the console detect if BC
> is present and then show a message and warning where appropriate
> where to get the jar and how to install if not.
I suggest we also take the step of removing the IDEA algorithms from the
SSL cipher suite list, otherwise the exposure scenario I outlined still
exists. The download of the bouncycastle code changes the behavior of
the SSL support without the Geronimo users having any control over the
matter. Removing those algorithms from the list removes that exposure.
>
> Then Geronimo is clean, the functionality is optional, and users have
> no risk of encountering a problem, unless they can't read.
>
> geir
>
> On Sep 1, 2005, at 1:36 PM, Rick McGuire wrote:
>
>> I found an interesting example of the inadverent problems that can
>> be caused by Geronimo's current usage of bouncycastle. The openejb
>> SunOrb codes specifies a list of supported cipher suites to be used
>> with SSL connections in the class SSLCipherSuiteDatabase. The
>> supported list includes the IDEA algorithms. The Sun default JCE
>> implemenation does not include IDEA, so this will not be used unless
>> additional JCE provides are installed which include IDEA support.
>> So far, so good. The IDEA code, even though listed as an option,
>> will not get used without explicit knowledge of the Gernonmo
>> administrator.
>>
>> However, the current console code uses the bouncycastle code to
>> implement its keystore. This usage is in a manner that requires the
>> BC provider code to be installed programmatically, which the console
>> code does. Unfortunately, once this is done, the IDEA algorithms
>> are now available for use for SSL connections as well. This server
>> is now potentially a royalty collection target by the IDEA patent
>> holders, since they can demonstrate usage by having a client connect
>> with this server using the IDEA ciphers. We might even want to
>> consider allowing these algorithms to be controlled by the server
>> config rather than just hard coding them in the class.
>>
>> One way to fix this is just remove the IDEA algorithms from the
>> SSLCipherSuiteDatabase, so these will not be used for SSL
>> connections. Another potential solution (yet to be verified) is to
>> use the BC APIs that allow the default JCE provider to be used for
>> encryption services rather than defaulting to the BC provider.
>>
>> Rick
>>
>>
>
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by Rick McGuire <ri...@gmail.com>.
btw, I want to point out the following notice from the bouncycastle site:
"Some of the algorithms in the Bouncy Castle APIs are patented in some
places. It is upon the user of the library to be aware of what the legal
situation is in their own situation, however we have been asked to
specifically mention the patent below at the request of the patent holder."
So far, the focus has just been on the IDEA patent...it appears there
are other patented algorithms in the bc code, but they only list patents
when they have been explicitly requested to by the patent holder.
Rick
Re: IDEA block cipher inclusion via the "bouncy castle" JCE provider
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
I was talking to Alan and mentioned this. He had another suggestion
- lets just (for now) get the ASN1 code from BC and package it
ourselves. Coupled with the suggestion about removing the IDEA
algorithm as a possibility, we remove the dep on BC in OpenEJB.
Then, we don't ship BC w/ geronimo, but let the console detect if BC
is present and then show a message and warning where appropriate
where to get the jar and how to install if not.
Then Geronimo is clean, the functionality is optional, and users have
no risk of encountering a problem, unless they can't read.
geir
On Sep 1, 2005, at 1:36 PM, Rick McGuire wrote:
> I found an interesting example of the inadverent problems that can
> be caused by Geronimo's current usage of bouncycastle. The openejb
> SunOrb codes specifies a list of supported cipher suites to be used
> with SSL connections in the class SSLCipherSuiteDatabase. The
> supported list includes the IDEA algorithms. The Sun default JCE
> implemenation does not include IDEA, so this will not be used
> unless additional JCE provides are installed which include IDEA
> support. So far, so good. The IDEA code, even though listed as an
> option, will not get used without explicit knowledge of the
> Gernonmo administrator.
>
> However, the current console code uses the bouncycastle code to
> implement its keystore. This usage is in a manner that requires
> the BC provider code to be installed programmatically, which the
> console code does. Unfortunately, once this is done, the IDEA
> algorithms are now available for use for SSL connections as well.
> This server is now potentially a royalty collection target by the
> IDEA patent holders, since they can demonstrate usage by having a
> client connect with this server using the IDEA ciphers. We might
> even want to consider allowing these algorithms to be controlled by
> the server config rather than just hard coding them in the class.
>
> One way to fix this is just remove the IDEA algorithms from the
> SSLCipherSuiteDatabase, so these will not be used for SSL
> connections. Another potential solution (yet to be verified) is to
> use the BC APIs that allow the default JCE provider to be used for
> encryption services rather than defaulting to the BC provider.
>
> Rick
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org