This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 209388 - Investigate use of native KeyStore as a keyring implementation
Summary: Investigate use of native KeyStore as a keyring implementation
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Keyring (show other bugs)
Version: 7.2
Hardware: All All
: P3 normal (vote)
Assignee: Libor Fischmeistr
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-09 16:00 UTC by Jesse Glick
Modified: 2012-10-30 19:26 UTC (History)
0 users

See Also:
Issue Type: TASK
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2012-03-09 16:00:12 UTC 
On some platforms, java.security.KeyStore may have an implementation which can store SecretKey's using a native keyring or encryption. In particular it seems that

1. OpenJDK 7 on Macs has apple.security.KeychainStore which can access the Keychain. Earlier (Apple) JDKs may have it too.

2. Windows JDKs have sun.security.mscapi.KeyStore which seems to access the Wincrypt library.

If these implementations are usable, they could supersede the current JNA-based variants in keyring.impl.

There do not appear to be any implementations for GNOME Keyring, KWallet, or Secret Service DBus API [1].

[1] http://www.freedesktop.org/wiki/Specifications/secret-storage-spec
Comment 1 Jesse Glick 2012-03-09 19:02:47 UTC 
For Gnome & KDE it may be possible to use D-Bus Java to access Secret Storage, though this is apparently not pure Java (needs libunixsocket-java) and is not installed by default on Ubuntu. /usr/bin/qdbus does not work for this API because you can only send one command at a time, and this service requires OpenSession and GetSecret to be called in the same connection.
Comment 2 Jesse Glick 2012-04-20 12:19:43 UTC 
(In reply to comment #1)
> needs libunixsocket-java

Possible solutions:

- distribute precompiled versions of its *.so
- using junixsocket (includes precompiled Linux *.so but not Solaris)
- rewriting libmatthew-unix to use JNA
- adapting {,Direct}MysqlUnixSocketFactory (but LGPL)
- adapting org.productivity.java.syslog4j.impl.unix.socket.UnixSocketSyslog (same origin)
Comment 3 Jesse Glick 2012-04-20 21:05:49 UTC 
(In reply to comment #0)
> apple.security.KeychainStore

http://lists.apple.com/archives/java-dev/2006/Jan/msg00124.html has a bit of info.

> sun.security.mscapi.KeyStore seems to access the Wincrypt library.

KeyStore.getInstance("Windows-MY") does load this. But security.cpp does not seem to call CryptProtectData (or CryptUnprotectData) at all. So that is not helpful.
Comment 4 Jesse Glick 2012-09-24 17:08:56 UTC 
(In reply to comment #2)
> (In reply to comment #1)
>> needs libunixsocket-java
> 
> Possible solutions:

https://github.com/ymnk/jsch-agent-proxy/blob/master/src/main/java/com/jcraft/jsch/agentproxy/usocket/JNAUSocketFactory.java
Comment 5 Jesse Glick 2012-10-30 19:26:53 UTC 
A side note: http://msdn.microsoft.com/en-us/library/windows/desktop/aa375187(v=vs.85).aspx implies that there _is_ some sort of standard credential store in Windows which could perhaps be used instead of CryptProtectData combined with custom storage, though it seems CRED_PERSIST_LOCALMACHINE is not universally supported. CredUIPromptForCredentials somehow related. May not be useful.