Swing Document Security?
Hi all,
I'm writing some software which uses the cryptographic API to read and write encrypted data. Obviously, we require all data to be nulled after it's used, and so the JPasswordField has a getPassword() method to this effect.
However, there is one minor problem... That appears to be the only part of the system which does include this. Specifically-
If I want to retrieve data in a JTextField, that data is manipulated by a Document object, which can only deal with String objects, meaning confidential data can leak out into memory and worse, pagefiles.
If I want to use JTextPane, that has the same issues. The only reason I mention it is that it is feasible to implement a secure JTextField from scratch, but to replicate the whole functionality of a JTextPane would be a nightmare.
So my question is this- if I want toactually sleep at night, and ensure the decrypted data doesn't hang around, am I basically going to have to reimplement everything from scratch?
I am even starting to feel my gut churn as I realise that even if Document did support char[] methods, the fact it also supports String methods could lead to accidental disclosure if you happen to call the wrong method or connect up the wrong object, and that this problem might hang around for the forseeable future.
Also, it would also be nice to be able to mark data as actually non-pagable (ala mlock() under linux, VirtualProtect under win32), but that is not possible in the current VM specification, and a copying/compacting gc would need to respect this. Are there any plans relating to this?
Thanks for any input on this one.
[1673 byte] By [
clnka] at [2007-10-1 23:44:03]
There is just no secure storage in Java, so I think the situation is even worse. I don't see any security guarantees anywhere in the JPasswordField class. Suppose you go ahead and zero out the character array returned. How do you know there isn't a copy somewhere below in the stack, or somewhere else in the GUI system.
So I don't think rewriting the JTextField component, or any other component, gets you what you want unless you're willing to write native methods. And even then it is tricky, as you allude to in your comment about wanting non-pageable memory.
Thanks for that input- you have confirmed/exacerbated my fears... And you are right, I see no contract which says this data will not be Stringified somewhere, it is merely implied by the JCE documents.
This is certainly an issue which needs to be explored further. As my understanding goes of the JVM internals- only the array reference would exist on the parameter stack or stack frame, and a single copy would exist in the heap- but at *bare* minimum, the data can be duplicated by any number of generational garbage collection algorithms, or just compacted to some new location. In the worst case as outlined previously, the Swing API is just not set up for the secure methodology Sun have espoused in their JCE guide.
And yes, I believe paging is *certainly* a risk, especially since we have very little control over what heap goes where, and the hotspot vm's desire to prealloc a huge heap encourages your OS to page it out at the first oppertunity. At bare minimum the ability to declare nonpagable classes (maybe a definition of the form 'public nopage class AuthenticationToken'... or such).
I think public awareness of these issues may need to be raised. Sure, maybe I'm the last to know, but it would still have been nice to have not had to discover it myself. The overall JCE architecture is good, but it is completely let down due to lack of foresight elsewhere in the libraries and vm. To the Swing developers I say- "Fix your API", it's pleasant to use most days, but it's ruining my party.
clnka at 2007-7-15 15:34:41 >
