Hi Greg, On Fri, Oct 2, 2020 at 7:32 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Sep 11, 2020 at 09:52:45AM -0400, Christopher Friedt wrote: > > Hi everyone, > > > > I thought it might be a good time to start / re-start / join the > > conversation about authentication and encryption in Greybus, and in > > particular, for using a transport (and lower layers) other than > > UniPro. This is the logical next step after getting the TCP/IP > > transport working with gbridge over BLE, 802.15.4, WiFi, ethernet, > > UART, etc. > > Wait, Greybus is transport-neutral, why are you trying to bake crypto > and authentication (two totally different things) into it? I agree that Greybus is transport-neutral, and am well aware that crypto and authentication are two totally different things. However, I am not suggesting that we bake auth and crypto into Greybus, or to be more specific, I also don't think that they belong in Greybus Core. > Why does this have to be part of GB at all? Can't the authentication > happen outside of the core and then when "all is good", the connection > is handed off to the GB core for the normal enumeration process? Thanks - that's a good suggestion, and really I'm looking for suggestions. I think that everyone interested should definitely weigh in. We could definitely use a separate layer that handles authentication for Greybus. The only reason I used Greybus messages to encapsulate that was because it was easy enough to do for a proof of concept. Are there any recommendations for a generic authentication protocol that can be used here? I found this [2] which shows OpenSSH using OAuth as a 2nd factor after public key authentication but I don't think that's what we're looking for (or is it?). Ideally, there would be an authentication layer that supports: * simple, point-to-point public key authentication, without referring to a third party * something like Oauth, for the convenience of authenticating with your mobile device * possibly FIDO? I know that it must have fairly small footprints for memory-constrained devices Oauth supports public-key authentication via PKCS #11 [3], but it's not clear to me if that requires a third party. Ideally I would use a generic authentication library that already exists for Zephyr, but I can't find anything that specifically does this. I know that they support mbedtls, but I'm can't tell if mbedtls supports any of the above requirements. > > For full negotiation of the auth mechanism and encryption algorithm > > (e.g. OAuth2 authentication + 3DES encryption) we'll probably need a > > few more message primitives, and likely a new minor version (at least) > > for each CPort protocol. > > > > It should be possible (although discouraged) to opt for everything in > > plaintext, but that would also be the default case for the CPort > > protocols as they exist today. As mentioned above, if not tunneling Greybus, and authentication & encryption were added as extensions outside of Greybus Core, plaintext would be the default case (i.e. "I am not suggesting that we bake auth and crypto into Greybus"). In the case that some other authentication library were not used, negotiating any kind of authentication and encryption would be completely optional: * "All Protocols shall be versioned, to allow future extensions (or fixes) to be added and recognized." - Chapter 7 of the spec * the Common Greybus Protocol Version Operation would be used first before making an attempt to use authentication or encryption (that would be a "shall" behaviour). * even if the Common Greybus Protocol Version Operation wasn't done first, and an unsupported Greybus message is received, GB_OP_INVALID is returned as a result [1] I can't seem to find the line of code in Linux, where an unsupported GB operation type is received, but I would imagine it's a similar result of GB_OP_INVALID. > What is the use-case here? "Traditionally" GB was done with wires, and > the data transport is not encrypted, nor does it need to be (like PCI > and USB and bucket-loads of other wired protocols). If you wish to put > GB over the network, the network connection itself can handle any needed > authentication to set up the connection, and then use any type of > encryption for the transport if it wants to, GB doesn't care. > > But, to get back to the original issue, why do you want authentication? > Do you authenticate your USB keyboard? Your PCI network card? Your > NVME disk? What is the usecase here? It's not currently standard practice to authenticate and encrypt traffic that goes over wires connecting devices but that's not to say it shouldn't be done in order to secure a system. With a sensitive enough software-defined radio it's entirely possible to decode a password typed on a USB keyboard from the next room over. In fact, exactly that was done at my previous place of employment. I think it's even possible to decode what appears on current monitors that use LVDS signalling using a similar method, to some level of SNR. > Same for crypto, why do you care about encrypting the datastream here? > What is the usecase? The use-case is really just secure communications. If I wanted to allow malicious people to perform a replay attack and open my front door or my garage door, or have the ability to set my thermostat or turn my lights off and on, then I would be happy to use plaintext for everything, but I'd rather not let malicious people do that. I think I understand where you're coming from though in terms of not wanting to disturb Greybus Core in any way. C [1] https://github.com/projectara/nuttx/blob/5bf12438cfff61121a900faa01b43506adcaa35c/nuttx/drivers/greybus/greybus-core.c#L206 [2] https://www.insecure.ws/linux/openssh_oath.html [3] https://openauthentication.org/wp-content/uploads/2015/09/ReferenceArchitectureVersion2.pdf _______________________________________________ greybus-dev mailing list greybus-dev@xxxxxxxxxxxxxxxx https://lists.linaro.org/mailman/listinfo/greybus-dev
|