[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1379599919-24763-1-git-send-email-dominik.paulus@fau.de>
Date: Thu, 19 Sep 2013 16:11:52 +0200
From: Dominik Paulus <dominik.paulus@....de>
To: usbip-devel@...ts.sourceforge.net
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Masanari Iida <standby24x7@...il.com>,
Dominik Paulus <dominik.paulus@....de>,
Tobias Polzer <tobias.polzer@....de>,
Kurt Kanzenbach <ly80toro@....cs.fau.de>,
Stefan Reif <ke42caxa@....cs.fau.de>,
Joe Perches <joe@...ches.com>,
Bart Westgeest <bart@...rys.com>,
Jake Champlin <jake.champlin.27@...il.com>,
Ilija Hadzic <ihadzic@...earch.bell-labs.com>,
Anthony Foiani <anthony.foiani@...il.com>,
Bernard Blackham <b-linuxgit@...gestprime.net>,
Harvey Yang <harvey.huawei.yang@...il.com>,
linux-usb@...r.kernel.org, devel@...verdev.osuosl.org,
linux-kernel@...cs.fau.de, linux-kernel@...r.kernel.org
Subject: [PATCH 0/7] staging: usbip: Extend crypto support
Hi,
this patch series extends our previous set of patches (see [1]). We extended
the crypto support so all of the usbip network traffic can now be completely
encrypted and authenticated.
We now use GnuTLS not only for password verification, but extend the lifetime
of the TLS connection to cover all of the userland communications. Before
handing over the connection to the kernel, two randomly generated 128 bit
session keys are exchanged between client and server and stored in sysfs
together with the sockfd. The kernel uses these keys to encrypt and
authenticate all of the traffic using AES-GCM and the linux crypto API.
Separate keys are used for both directions of the data channel.
To the best of our knowledge, the implemented encryption should provide decent
security. However, it still lacks complete review; we also note that in the
documentation.
As mentioned in the project README, the network protocol needs more discussion.
This series increments the protocol version, because the improved crypto
support breaks compatibility with the previous patch series[1]. In the long
term, the protocol should be extended to support proper feature negotiation. If
both patch series are merged as one, the protocol version increment can be
omitted - both patch series are compatible with unauthenticated transport, but
are incompatible with each other.
Regards,
Tobias Polzer and Dominik Paulus
[1] <1379066161-8278-1-git-send-email-dominik.paulus@....de>,
https://lkml.org/lkml/2013/9/13/104
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists