[PATCH] Add Android keystore support

[David Woodhouse]

On Thu, 2011-12-29 at 10:59 +0000, David Woodhouse wrote:
> That looks better. My only remaining gripe is that you expose the
> 'keystore' key type even when it's not available. That should be in
> #ifdef ANDROID too, shouldn't it?
> 
> We should also possibly update the man page?

Looking back at this... did I ever get a patch which addressed the
above? I don't seem to have actually committed anything.

> > > Also, I wonder if we're using the Android keystore correctly. It looks
> > > like you are extracting the private key from the keystore and
> > > *importing* it into OpenSSL. But if it's a TPM or crypto token or
> > > something like that, it shouldn't *allow* that operation. It'll *use*
> > > the key for you, but it won't just *give* it to you. And a well-designed
> > > OS key store shouldn't allow that either. Are you *sure* that's what
> > > you're supposed to do?
> > 
> > Pretty sure, the android keystore is basically just a database service
> > for storing key-value pairs used for security purposes (wifi passwords
> >  certificates, etc).
> 
> Hm, that sounds like a bloody stupid design for a key store that can
> store SSL keys. Either that, or storing SSL keys in it is
> inappropriate. 

Having seen a little more of Android, I am no longer surprised by such
stupid design decisions :(

> > > Also, have you looked at the Android authentication GUI at
> > > https://github.com/srinathduraisamy/OpenConnect ? 
> > 
> > What is this app supposed to do?  With our vpn concentrator it just says
> > 'No peer certificate'.

Srinath has updated it to handle unknown certificates gracefully now. As
I said before, it basically handles the authentication part up to
obtaining the cookie that you need to connect with.

I think it would be a good basis for a root-less app which uses the ICS
VPN service.

The only complication is that Android's VPN service handles the 'route
all packets through the VPN *except* the ones we're actually trying to
send to the VPN server' thing differently. Rather than just telling it
the IP address of the server and letting it set up a host-specific route
through the "real" network, as vpnc-script does, we instead "protect"
the socket(s) that connect us to the server:
http://developer.android.com/reference/android/net/VpnService.html#protect%28int%29

I'm not entirely sure what that does behind the scenes; perhaps
SO_BINDTODEVICE or something like that?

So we'll need to make sure that the sockets openconnect uses for talking
to the server are "protected". One option is to create the sockets *for*
it and pass them in (with --cstp-fd=5 --dtls-fd=6 or something like that
on the command line). But that won't work well if a connection is lost
and openconnect has to make a new one. Perhaps it could *exit* then, and
make us re-invoke it?

If handling the socket protection from C code is hard, it might make
sense just to reimplement OpenConnect *completely* in Java. The TCP part
is dead easy, and if we can do Cisco's speshul version of DTLS from Java
too (perhaps by calling OpenSSL?) then that shouldn't be too hard
either.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6171 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120505/ce9ef806/attachment.bin>