Vulnerabilities due to BigInteger being immutable?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Vulnerabilities due to BigInteger being immutable?

Kevin Smith-2
Greetings,

As part of an internal security audit process, we uncovered some
potential vulnerabilities, and I have been asked to share them with you
and solicit feedback. We realize that these are probably relatively low
risk concerns, but would like some reassurance that they really are.

RSA private keys are stored internally as BigIntegers. Because
BigIntegers are immutable (Sun's decision), it is impossible to clear
them. Once some memory location contains a private key, there is no
reliable way to wipe it.

This opens up three possible attacks that we can think of:

1) Memory can be scanned while the app is running, or after it exits,
and the key could be extracted. The app has no way to clear the key when
it is finished using it.

An attacker would not have to know exactly where in memory the key is
stored--they could brute-force try all the possible locations in RAM.
This would only require perhaps billions or trillions of attempts, far
less than the normal strength of a 2048 bit RSA key. The same is true
for #2 and #3, below.

As has been pointed out on this list, an attacker capable of scanning
memory on a secure system such as a server is probably able to perform
other more effective attacks. On a relatively insecure workstation,
there are likely to be other more serious vulnerabilities that could be
exploited. So the simple case of memory scanning does not seem to be a
serious risk in most cases.

2) Memory may be swapped to disk, so the swap file could be scanned.
Swap files may potentially exist after a computer has been shut down.
Even after a disk sector has been overwritten it may be possible to
retrieve earlier data stored in that location. This exposure is most
significant in cases where the computer may get stolen (which happens to
be a real consideration in our domain).

3) After losing power, DRAM retains a faint image of the data it used to
contain, potentially allowing the old data to be recovered for hours, or
perhaps days after the power has been shut off[1].

The longer a particular bit pattern is stored, the stronger the
persistent image. So the easiest way to mitigate this would be to move
the key around in memory frequently. Unfortunately, because BigIntegers
are immutable, this isn't really possible (they could only be copied,
making the problem worse). Again, this risk becomes most interesting if
the computer is stolen.


We would appreciate any feedback as to whether we have overstated or
understated any of the risks above. Also, we would be interested to hear
if there are any steps we might take to mitigate any of them. Of course,
we would also be interested in hearing about any similar or related
attacks that we have not thought of. Are any of these risks high enough
to warrant exploring replacing BigInteger with a mutable (wipeable)
alternative?

Thanks!

Kevin

[1] http://www.totse.com/en/technology/computer_technology/161780.html

Reply | Threaded
Open this post in threaded view
|

Re: Vulnerabilities due to BigInteger being immutable?

Megan Woods-2

Hi Kevin,

One way to look at it is to consider that if the attacker has got access
to your machine to the point where they can walk the heap and examine
memory, then your system is compromised and there are not a whole lot of
solutions for this.

My advice is to focus on the physical security, the software integrity
of the machine and the trustworthiness of the users.

Cheers

Megan Woods



Kevin Smith wrote:

> Greetings,
>
> As part of an internal security audit process, we uncovered some
> potential vulnerabilities, and I have been asked to share them with
> you and solicit feedback. We realize that these are probably
> relatively low risk concerns, but would like some reassurance that
> they really are.
>
> RSA private keys are stored internally as BigIntegers. Because
> BigIntegers are immutable (Sun's decision), it is impossible to clear
> them. Once some memory location contains a private key, there is no
> reliable way to wipe it.
>
> This opens up three possible attacks that we can think of:
>
> 1) Memory can be scanned while the app is running, or after it exits,
> and the key could be extracted. The app has no way to clear the key
> when it is finished using it.
>
> An attacker would not have to know exactly where in memory the key is
> stored--they could brute-force try all the possible locations in RAM.
> This would only require perhaps billions or trillions of attempts, far
> less than the normal strength of a 2048 bit RSA key. The same is true
> for #2 and #3, below.
>
> As has been pointed out on this list, an attacker capable of scanning
> memory on a secure system such as a server is probably able to perform
> other more effective attacks. On a relatively insecure workstation,
> there are likely to be other more serious vulnerabilities that could
> be exploited. So the simple case of memory scanning does not seem to
> be a serious risk in most cases.
>
> 2) Memory may be swapped to disk, so the swap file could be scanned.
> Swap files may potentially exist after a computer has been shut down.
> Even after a disk sector has been overwritten it may be possible to
> retrieve earlier data stored in that location. This exposure is most
> significant in cases where the computer may get stolen (which happens
> to be a real consideration in our domain).
>
> 3) After losing power, DRAM retains a faint image of the data it used
> to contain, potentially allowing the old data to be recovered for
> hours, or perhaps days after the power has been shut off[1].
>
> The longer a particular bit pattern is stored, the stronger the
> persistent image. So the easiest way to mitigate this would be to move
> the key around in memory frequently. Unfortunately, because
> BigIntegers are immutable, this isn't really possible (they could only
> be copied, making the problem worse). Again, this risk becomes most
> interesting if the computer is stolen.
>
>
> We would appreciate any feedback as to whether we have overstated or
> understated any of the risks above. Also, we would be interested to
> hear if there are any steps we might take to mitigate any of them. Of
> course, we would also be interested in hearing about any similar or
> related attacks that we have not thought of. Are any of these risks
> high enough to warrant exploring replacing BigInteger with a mutable
> (wipeable) alternative?
>
> Thanks!
>
> Kevin
>
> [1] http://www.totse.com/en/technology/computer_technology/161780.html
>
>
>





Reply | Threaded
Open this post in threaded view
|

Re: Vulnerabilities due to BigInteger being immutable?

Will Dickson
In reply to this post by Kevin Smith-2

Kevin Smith wrote:

[snip]

> As has been pointed out on this list, an attacker capable of scanning
> memory on a secure system such as a server is probably able to perform
> other more effective attacks. On a relatively insecure workstation,
> there are likely to be other more serious vulnerabilities that could be
> exploited. So the simple case of memory scanning does not seem to be a
> serious risk in most cases.

I would agree with this. Our approach has always been that if the
attacker has that level of access to your hardware, you've lost.

>
> 2) Memory may be swapped to disk, so the swap file could be scanned.
> Swap files may potentially exist after a computer has been shut down.
> Even after a disk sector has been overwritten it may be possible to
> retrieve earlier data stored in that location. This exposure is most
> significant in cases where the computer may get stolen (which happens to
> be a real consideration in our domain).
>
> 3) After losing power, DRAM retains a faint image of the data it used to
> contain, potentially allowing the old data to be recovered for hours, or
> perhaps days after the power has been shut off[1].
>
> The longer a particular bit pattern is stored, the stronger the
> persistent image. So the easiest way to mitigate this would be to move
> the key around in memory frequently.

Such an "agile" key would presumably be less likely to be swapped as
well, since it keeps being touched.

One idea, which might well be rubbish but I'll mention it anyway: since
keys are opaque (in the JCA/JCE anyway), rather than storing the key as
a BigInteger internally, why not store it as a byte[]? This can then be
moved around at random (as, indeed, can symmetric keys - we use BC for
data storage as well as data comms, so we have to worry about symmetric
key management as well). When the key needs to be used, it gets
converted into a one-shot BigInteger, used for that operation only; then
the reference is nulled and System.gc() is called. In this way it's much
more likely that, when the time comes, the BigInt will be thrown away
rather than swapped.

Clearly this introduces extra overhead. OTOH my own (crude)
investigations indicate that memory allocation is very cheap in Java
(J2SE anyway - J2ME I haven't a clue about), so compared to the horrible
overheads that this operation is likely to be associated with in any
case - public-key, ASN.1 manipulation etc - this extra would probably be
negligible. If you wanted, you could have some kind of configuration
properties or whatnot to tune the behaviour.

However, there's another argument. One of the downsides of Java's
hardware independence is that you lose control over the hardware. All of
the above hackery is predicated on guessing how the JVM is likely to
behave: while this guess is more likely to be correct than not, you
certainly have no guarantee, or even a beyond-reasonable-doubt level of
evidence. All you really have is a balance of probabilities, and that
simply isn't good enough to base any kind of proper security analysis on.

If these kinds of attack are a realistic threat for you, then you a)
need a much more rigorous, context-dependent threat analysis than can be
attempted in a general-purpose library such as BC; and b) probably need
tighter control over the hardware than a Java system can give you.

HTH, and thanks to all the legion for providing such a great library.

Will.


Reply | Threaded
Open this post in threaded view
|

Re: Vulnerabilities due to BigInteger being immutable?

David Hook-4
In reply to this post by Kevin Smith-2

I'm not sure if this really has much to do with BigIntegers being
immutable - the fact you have to decrypt the private key in memory is
enough, assuming you're not using an OS that protects against it, it's
just a question of how much work someone has to do and the approach they
need to take (and the "easiest" approach is probably still a lot more
work than most would be capable of - they're more likely to find some
other way of getting the information).

Reading through this it sounds like there are two considerations with
the system you're working with. The first is the ability to detect
intruders if a box connected to the network is compromised, the second
is what to do about private credentials stored on a box that might be
stolen. It sounds like you're already aware of the first one but that
the second one is still a bit of an issue.

Regardless of the technical problems an attacker would face trying to
launch an attack trying to achieve attacks 2 and 3 on a piece of stolen
hardware, the easiest solution would be to organise things such that
there is no point in doing 2 or 3. Assuming you can tell if a piece of
hardware has been compromised or stolen, is there any reason why you
would still regard it's private credentials as valid? What actual value
are they to an attacker? If the credentials associated with compromised
hardware are quickly revoked there is unlikely to be any point in
someone trying to recover them.

Regards,

David

On Mon, 2005-08-29 at 16:20 -0400, Kevin Smith wrote:

> Greetings,
>
> As part of an internal security audit process, we uncovered some
> potential vulnerabilities, and I have been asked to share them with you
> and solicit feedback. We realize that these are probably relatively low
> risk concerns, but would like some reassurance that they really are.
>
> RSA private keys are stored internally as BigIntegers. Because
> BigIntegers are immutable (Sun's decision), it is impossible to clear
> them. Once some memory location contains a private key, there is no
> reliable way to wipe it.
>
> This opens up three possible attacks that we can think of:
>
> 1) Memory can be scanned while the app is running, or after it exits,
> and the key could be extracted. The app has no way to clear the key when
> it is finished using it.
>
> An attacker would not have to know exactly where in memory the key is
> stored--they could brute-force try all the possible locations in RAM.
> This would only require perhaps billions or trillions of attempts, far
> less than the normal strength of a 2048 bit RSA key. The same is true
> for #2 and #3, below.
>
> As has been pointed out on this list, an attacker capable of scanning
> memory on a secure system such as a server is probably able to perform
> other more effective attacks. On a relatively insecure workstation,
> there are likely to be other more serious vulnerabilities that could be
> exploited. So the simple case of memory scanning does not seem to be a
> serious risk in most cases.
>
> 2) Memory may be swapped to disk, so the swap file could be scanned.
> Swap files may potentially exist after a computer has been shut down.
> Even after a disk sector has been overwritten it may be possible to
> retrieve earlier data stored in that location. This exposure is most
> significant in cases where the computer may get stolen (which happens to
> be a real consideration in our domain).
>
> 3) After losing power, DRAM retains a faint image of the data it used to
> contain, potentially allowing the old data to be recovered for hours, or
> perhaps days after the power has been shut off[1].
>
> The longer a particular bit pattern is stored, the stronger the
> persistent image. So the easiest way to mitigate this would be to move
> the key around in memory frequently. Unfortunately, because BigIntegers
> are immutable, this isn't really possible (they could only be copied,
> making the problem worse). Again, this risk becomes most interesting if
> the computer is stolen.
>
>
> We would appreciate any feedback as to whether we have overstated or
> understated any of the risks above. Also, we would be interested to hear
> if there are any steps we might take to mitigate any of them. Of course,
> we would also be interested in hearing about any similar or related
> attacks that we have not thought of. Are any of these risks high enough
> to warrant exploring replacing BigInteger with a mutable (wipeable)
> alternative?
>
> Thanks!
>
> Kevin
>
> [1] http://www.totse.com/en/technology/computer_technology/161780.html
>


Reply | Threaded
Open this post in threaded view
|

Re: Vulnerabilities due to BigInteger being immutable?

R. P. Ruiz
Greetings colegas!

Here's a quick, off the cuff response which may or may not be relevant:

When looking at using Strings (which are supposed to be immutable) to
contain data whose lifespan I wanted to control, I ended up finding a
cryptic remark that introspection might be used to solve that problem.

It turns out it could be used to solve that problem: after doing a bit
of research and experimenting, I ended up w/ what amounts to a String
wiper, that fills a given String's char array w/ junk whenever I wish.
So while the lifetime of the String is out of my control, I can
overwrite its contents, giving me more or less the same effect.

I'm not certain that would be possible w/ BigInteger, since I haven't
looked at the source.  If you want I could forward you the code that I
use to wipe Strings, it may end up being a useful starting point.

Operators are standing by,

Rick

David Hook wrote:

> I'm not sure if this really has much to do with BigIntegers being
> immutable - the fact you have to decrypt the private key in memory is
> enough, assuming you're not using an OS that protects against it, it's
> just a question of how much work someone has to do and the approach they
> need to take (and the "easiest" approach is probably still a lot more
> work than most would be capable of - they're more likely to find some
> other way of getting the information).
>
> Reading through this it sounds like there are two considerations with
> the system you're working with. The first is the ability to detect
> intruders if a box connected to the network is compromised, the second
> is what to do about private credentials stored on a box that might be
> stolen. It sounds like you're already aware of the first one but that
> the second one is still a bit of an issue.
>
> Regardless of the technical problems an attacker would face trying to
> launch an attack trying to achieve attacks 2 and 3 on a piece of stolen
> hardware, the easiest solution would be to organise things such that
> there is no point in doing 2 or 3. Assuming you can tell if a piece of
> hardware has been compromised or stolen, is there any reason why you
> would still regard it's private credentials as valid? What actual value
> are they to an attacker? If the credentials associated with compromised
> hardware are quickly revoked there is unlikely to be any point in
> someone trying to recover them.
>
> Regards,
>
> David
>
> On Mon, 2005-08-29 at 16:20 -0400, Kevin Smith wrote:
>
>>Greetings,
>>
>>As part of an internal security audit process, we uncovered some
>>potential vulnerabilities, and I have been asked to share them with you
>>and solicit feedback. We realize that these are probably relatively low
>>risk concerns, but would like some reassurance that they really are.
>>
>>RSA private keys are stored internally as BigIntegers. Because
>>BigIntegers are immutable (Sun's decision), it is impossible to clear
>>them. Once some memory location contains a private key, there is no
>>reliable way to wipe it.
>>
>>This opens up three possible attacks that we can think of:
>>
>>1) Memory can be scanned while the app is running, or after it exits,
>>and the key could be extracted. The app has no way to clear the key when
>>it is finished using it.
>>
>>An attacker would not have to know exactly where in memory the key is
>>stored--they could brute-force try all the possible locations in RAM.
>>This would only require perhaps billions or trillions of attempts, far
>>less than the normal strength of a 2048 bit RSA key. The same is true
>>for #2 and #3, below.
>>
>>As has been pointed out on this list, an attacker capable of scanning
>>memory on a secure system such as a server is probably able to perform
>>other more effective attacks. On a relatively insecure workstation,
>>there are likely to be other more serious vulnerabilities that could be
>>exploited. So the simple case of memory scanning does not seem to be a
>>serious risk in most cases.
>>
>>2) Memory may be swapped to disk, so the swap file could be scanned.
>>Swap files may potentially exist after a computer has been shut down.
>>Even after a disk sector has been overwritten it may be possible to
>>retrieve earlier data stored in that location. This exposure is most
>>significant in cases where the computer may get stolen (which happens to
>>be a real consideration in our domain).
>>
>>3) After losing power, DRAM retains a faint image of the data it used to
>>contain, potentially allowing the old data to be recovered for hours, or
>>perhaps days after the power has been shut off[1].
>>
>>The longer a particular bit pattern is stored, the stronger the
>>persistent image. So the easiest way to mitigate this would be to move
>>the key around in memory frequently. Unfortunately, because BigIntegers
>>are immutable, this isn't really possible (they could only be copied,
>>making the problem worse). Again, this risk becomes most interesting if
>>the computer is stolen.
>>
>>
>>We would appreciate any feedback as to whether we have overstated or
>>understated any of the risks above. Also, we would be interested to hear
>>if there are any steps we might take to mitigate any of them. Of course,
>>we would also be interested in hearing about any similar or related
>>attacks that we have not thought of. Are any of these risks high enough
>>to warrant exploring replacing BigInteger with a mutable (wipeable)
>>alternative?
>>
>>Thanks!
>>
>>Kevin
>>
>>[1] http://www.totse.com/en/technology/computer_technology/161780.html
>>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Vulnerabilities due to BigInteger being immutable?

Kevin Smith-2
Thanks to everyone who has responded!

I wanted to share a bit more context, because some of the suggestions
(while perfectly valid) are not practical for our application. Our
situation has some "impossible" requirements, but we're still trying to
provide the best security we can, given the contraints.

Our software is distributed at zero-cost and is used by folks around the
world with no money available to buy crypto hardware. It is a desktop
app, with no centralized administrator and no authoritative server. Many
users don't even have a reliable internet connection, and most work out
of their home or a low-security office. Incidentally, this app is not
useful for violating copyrights, in case that's what you're thinking.

Our biggest concern (in the context of this thread) is protecting the
privacy of the encrypted data stored on the user's computer. That's why
we are hoping to prevent attackers from obtaining the private key if
they gain physical posession of a powered-off workstation. Key
revocation is a relatively minor point for us.

Here are replies to a few specific comments...


R. P. Ruiz wrote:
> I'm not certain that would be possible w/ BigInteger, since I haven't
> looked at the source.  If you want I could forward you the code that I
> use to wipe Strings, it may end up being a useful starting point.

I would be interested in seeing that.


Will Dickson wrote:
 > One idea, which might well be rubbish but I'll mention it anyway:
 > since keys are opaque (in the JCA/JCE anyway), rather than storing the
 > key as a BigInteger internally, why not store it as a byte[]? This can
 > then be moved around at random (as, indeed, can symmetric keys - we
 > use BC for data storage as well as data comms, so we have to worry
 > about symmetric key management as well). When the key needs to be
 > used, it gets converted into a one-shot BigInteger, used for that
 > operation only; then the reference is nulled and System.gc() is
 > called. In this way it's much more likely that, when the time comes,
 > the BigInt will be thrown away rather than swapped.

Yes, we would like to do something like that. It would be even better if
we could wipe the BigInt immediately after we're done with it. If BigInt
were mutable, we could XOR it in-place when we're not using it, and
re-XOR it when we need it. That way, any latent or swapped versions
would be likely to be unusable.

 > However, there's another argument. One of the downsides of Java's
 > hardware independence is that you lose control over the hardware.

Very true. But it is still worthwhile to try to have only 1 swapped copy
instead of 10, or have a latent RAM image only be recoverable for 5
minutes after power-off instead of 2 days. Security is a spectrum, not a
binary value.



I'm still disappointed that BigInteger is immutable, because that
prevents us from taking some very simple and effective steps to improve
security. Sun went to the bother of making passwords use char[] instead
of Strings so they could be wiped. Private keys are even more precious
than passwords, but they get no protection.

Cheers,

Kevin

Reply | Threaded
Open this post in threaded view
|

Re: Vulnerabilities due to BigInteger being immutable?

Otto Moerbeek

On Thu, 1 Sep 2005, Kevin Smith wrote:

> I'm still disappointed that BigInteger is immutable, because that prevents us
> from taking some very simple and effective steps to improve security. Sun went
> to the bother of making passwords use char[] instead of Strings so they could
> be wiped. Private keys are even more precious than passwords, but they get no
> protection.

There's a very dirty trick possible using introspection. This may not
work in your environment because it uses a non-default securitymanager
and it uses internal implementation details, but here's the idea:

import java.math.BigInteger;
import java.lang.reflect.Field;

public class B {
  public static void main(String args[]) throws Exception {

    BigInteger key = new BigInteger("1");

    //Field[] flds = BigInteger.class.getDeclaredFields();
    //for (int i = 0; i < flds.length ; i++)
    // System.out.println(flds[i]);
    Field f1 = BigInteger.class.getDeclaredField("mag");
    f1.setAccessible(true);
    System.out.println(key);
   
    int[] a1 = (int[]) f1.get(key);
    for (int i = 0; i < a1.length; i++)
        a1[i] = 0;
    System.out.println(key);
  }
}

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: Vulnerabilities due to BigInteger being immutable?

Otto Moerbeek




On Thu, 1 Sep 2005, Otto Moerbeek wrote:

>
> On Thu, 1 Sep 2005, Kevin Smith wrote:
>
> > I'm still disappointed that BigInteger is immutable, because that prevents us
> > from taking some very simple and effective steps to improve security. Sun went
> > to the bother of making passwords use char[] instead of Strings so they could
> > be wiped. Private keys are even more precious than passwords, but they get no
> > protection.
>
> There's a very dirty trick possible using introspection. This may not
> work in your environment because it uses a non-default securitymanager

This 'it' means 'your environment'.

> and it uses internal implementation details, but here's the idea:

This 'it' mean the little program. Sorry to be confusing,

        -Otto
       

>
> import java.math.BigInteger;
> import java.lang.reflect.Field;
>
> public class B {
>   public static void main(String args[]) throws Exception {
>
>     BigInteger key = new BigInteger("1");
>
>     //Field[] flds = BigInteger.class.getDeclaredFields();
>     //for (int i = 0; i < flds.length ; i++)
>     // System.out.println(flds[i]);
>     Field f1 = BigInteger.class.getDeclaredField("mag");
>     f1.setAccessible(true);
>     System.out.println(key);
>    
>     int[] a1 = (int[]) f1.get(key);
>     for (int i = 0; i < a1.length; i++)
> a1[i] = 0;
>     System.out.println(key);
>   }
> }
>
> -Otto
>
>

Reply | Threaded
Open this post in threaded view
|

do i need to pay anything to use bouncycastle's openpgp library?

Cadbury
hi

I'm a freelance software developer, and i would like
to develop a program which utilize the bouncycastle's
openpgp library, then perhaps i would like to sell
them.

Do i need to pay any royalty/fees to bouncycastle or
any respective parties? And what kind of disclaimer
should i put in my software?

Any information is greatly appreciated. Thanks


               
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs 
 

Reply | Threaded
Open this post in threaded view
|

Re: Vulnerabilities due to BigInteger being immutable?

R. P. Ruiz
In reply to this post by Otto Moerbeek
Greetings!

Otto's done w/ BigInteger what I've done w/ Strings to make them mutable.

While I agree that it's a kind of kludgey trick to have to introspect
the String/BigInteger objs in order to touch their data, I'm not certain
about the statement that it uses a non-default security manager.  Unless
I'm mistaken (always possible!), the default security manager is always
used unless specifically directed to do otherwise.

The StringWiper code works on Sun's and Apple's 1.4.x and 1.5.x JVMs on
win32, Linux, and OS X, and I've always used the default security
manager.  Your mileage may vary, of course ;-)

BTW, Otto's code sample makes an explicit reference to the field "mag",
which is something that never worked in my StringWiper (although the
exact reason I can't remember).  As a result I ended up iterating the
fields until I find the "value" field.  One alternative to explicitly
referring to the field's name (which may be subject to change) would be
to check field types.  As I remember, String's "value" field is the only
char[] contained w/in  String's implementation, and a fairly safe bet
not to change in the future.

I've included the source to StringWiper.  Have fun lining your bird
cages w/ it ;-)

Great thread!

Rick

Otto Moerbeek wrote:
>
> ...BIG SNIP...
>
>>There's a very dirty trick possible using introspection. This may not
>>work in your environment because it uses a non-default securitymanager
>
>...BIG SNIP...
 >

>>import java.math.BigInteger;
>>import java.lang.reflect.Field;
>>
>>public class B {
>>  public static void main(String args[]) throws Exception {
>>
>>    BigInteger key = new BigInteger("1");
>>
>>    //Field[] flds = BigInteger.class.getDeclaredFields();
>>    //for (int i = 0; i < flds.length ; i++)
>>    // System.out.println(flds[i]);
>>    Field f1 = BigInteger.class.getDeclaredField("mag");
>>    f1.setAccessible(true);
>>    System.out.println(key);
>>  
>>    int[] a1 = (int[]) f1.get(key);
>>    for (int i = 0; i < a1.length; i++)
>> a1[i] = 0;
>>    System.out.println(key);
>>  }
>>}
>>
>> -Otto

/*
 * Moonbounce Crypto API: High level wrapper classes for Bouncycastle's
 * lightweight crypto library. Copyright (C) 2004-2005 R. P. Ruiz and
 * txikisoft.
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Lesser General Public License for more details.
 *
 *   You should have received a copy of the GNU Lesser General Public
 *   License along with this library; if not, write to the Free Software
 *   Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 *
 * You may contact this library's author, R. P. Ruiz, via email at
 * [hidden email].
 *
 */

package com.txikisoft.lib.moonbounce.wipers;

import java.lang.reflect.Method;
import java.lang.reflect.Field;

public class StringWiper {

    //boolean debug;
   
    private StringWiper() {
    }
    /*
    public StringWiper( boolean d ) {
        debug = d;
    }
    public void setDebug( boolean d ) {
        debug = d;
    }
    */
    public static void zeroThisString( String toBeZeroed ) throws IllegalAccessException {
       
        zeroThisString( toBeZeroed, '*' );
    }
    public static void zeroThisString( String toBeZeroed, char substitute ) throws IllegalAccessException {
       
        Class cls = toBeZeroed.getClass();
           
        Field[] f = cls.getDeclaredFields();
        Field currentField;
       
        for (int i = 0; i < f.length; i++) {

            currentField = f[ i ];
            if ( currentField.getName().equals( "value" ) ) {

                // if ( debug ) System.out.println( "[" + currentField.getName() + "], of type [" + currentField.getType() +"] is accessable [" + currentField.isAccessible() + "].  " );                                
                // if ( debug ) System.out.println( "setting currentField.setAccessible( true )..." );
                currentField.setAccessible( true );
                // if ( debug ) System.out.println( "setting currentField.setAccessible( true )...FINISHED!" );
                // if ( debug ) System.out.println( "[" + currentField.getName() + "], of type [" + currentField.getType() +"] is accessable [" + currentField.isAccessible() + "].  " );                                
               
                char[] underlyingChars;

                underlyingChars = (char[])currentField.get( toBeZeroed );
                // if ( debug ) System.out.println( "underlyingChars (before): " + new String( underlyingChars ) );            
                // if ( debug ) System.out.println( "     toBeZeroed (before): " + toBeZeroed );            
                for ( int j = 0; j < underlyingChars.length; j++ ) {

                    underlyingChars[ j ] = substitute;
                }
                underlyingChars = (char[])currentField.get( toBeZeroed );
                // if ( debug ) System.out.println( "underlyingChars (after): " + new String( underlyingChars ) );            
                // if ( debug ) System.out.println( "     toBeZeroed (after): " + toBeZeroed );            
               
                break;
            }
        }
    }
    public static final void main( String[] args ) {        
       
        try {
           
            long start = System.currentTimeMillis();
           
            //StringWiper wiper = new StringWiper( true );
            String foo = "Foobert! Wherefore art thou Foobert?";
            System.out.println( "foo (before): " + foo );
            StringWiper.zeroThisString( foo, '*' );
            System.out.println( " foo (after): " + foo );
           
            System.out.println( "time to wipe: [" + ( System.currentTimeMillis() - start ) + "] ms" );
           
        } catch (Throwable e) {
            System.err.println(e);
        }
       
    }
}
Reply | Threaded
Open this post in threaded view
|

Re: do i need to pay anything to use bouncycastle's openpgp library?

David Hook-4
In reply to this post by Cadbury
No fees. Be aware that depending on where you are there may be patents,
and their associated licence fees, applicable to what you are doing
though (not necessarily BC related either).

You just need to include our licence to refer to the parts of the BC
library you use other than that it's all yours.

Regards,

David

On Thu, 2005-09-01 at 09:05 -0700, Cadbury wrote:

> hi
>
> I'm a freelance software developer, and i would like
> to develop a program which utilize the bouncycastle's
> openpgp library, then perhaps i would like to sell
> them.
>
> Do i need to pay any royalty/fees to bouncycastle or
> any respective parties? And what kind of disclaimer
> should i put in my software?
>
> Any information is greatly appreciated. Thanks
>
>
>
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs 
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Vulnerabilities due to BigInteger being immutable?

Otto Moerbeek
In reply to this post by R. P. Ruiz


On Fri, 2 Sep 2005, R. P. Ruiz wrote:

> Greetings!
>
> Otto's done w/ BigInteger what I've done w/ Strings to make them mutable.
>
> While I agree that it's a kind of kludgey trick to have to introspect the
> String/BigInteger objs in order to touch their data, I'm not certain about the
> statement that it uses a non-default security manager.  Unless I'm mistaken
> (always possible!), the default security manager is always used unless
> specifically directed to do otherwise.

As an example, Applets and EJBs run in an environment witgh a non-default
security manager.

        -Otto