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?
> There is the Component Authentication Protocol that exists already,
> but I'm not terribly familiar with it. Is anyone able to clarify if
> there is some overlap between CAP and some of the work that follows?
> If it's possible to re-use some of the CAP, that would be nice.
>
> Just over a year ago I set up authentication and encryption over
> Greybus for BeagleBoard.org. I was able to demonstrate it working over
> a TCP/IP transport. Here is some code that is on the back-burner for
> now.
>
> https://github.com/friedtco/gbridge/blob/feature/tcpip-ble-ipsp/pkauth.h
> https://github.com/friedtco/gbridge/blob/feature/tcpip-ble-ipsp/pkauth.c
>
> I have a PR open to anobli/gbridge on GitHub that pulls in the
> non-authentication / encryption changes. So the change that deals with
> auth and encryption is fairly small. On the Host side, it uses
> OpenSSL.
>
> We are using regular SSH keys for asymmetric authentication and the
> initial secure channel, then generating and sharing an AES-128 session
> key for symmetric encryption of the subsequent communications. The
> wireless SoC we're using for testing is the CC1352R from TI, and it
> has both AES and PK hardware accelerators. Most SoC's these days have
> an AES accelerator, at least.
>
> The handshake is described here, but I'll copy it into the email as well.
>
> https://github.com/friedtco/gbridge/blob/feature/tcpip-ble-ipsp/pkauth.c#L1161
>
> 1. Device sends its public key
> 2. Host compares device public key with those in a collection of
> trusted public keys. if not found connection closed.
> 3. Host sends its public key
> 4. Device compares host public key with those in a collection of
> trusted public keys. if not found connection closed.
> 5. Device creates a randomly generated message, "PlainText A".
> 6. Device encrypts "PlainText A" using Host public key, creating "CipherText A".
> 7. Device transmits "CipherText A" to Host.
> 8. Host decrypts "CipherText A" with Host private key, resulting in
> "PlainText B".
> 9. Host encrypts "PlainText B" using Device public key, creating "CipherText B".
> 10. Host transmits "CipherText B" to Device.
> 11. Device decrypts "CipherText B" with Device private key, resulting
> in "PlainText C".
> 12. Device compares "PlainText A" and "PlainText C", and responds with
> success or noauth.
> 13. Host creates a randomly generated message, "PlainText D".
> 14. Host encrypts "PlainText D" using Device public key, creating
> "CipherText D".
> 15. Host transmits "CipherText D" to Device.
> 16. Device decrypts "CipherText D" with Device private key, resulting
> in "PlainText E".
> 17. Device encrypts "PlainText E" using Host public key, creating
> "CipherText E".
> 18. Device transmits "CipherText E" to Host.
> 19. Host decrypts "CipherText E" with Host private key, resulting in
> "PlainText F".
> 20. Host compares "PlainText D" and "PlainText F", and responds with
> success or noauth.
> 21. Host generates symmetric session key as "PlainText G", pairs
> session key with socket.
> 22. Host encrypts "PlainText G" with Device public key, resulting in
> "CipherText G".
> 23. Host transmits "CipherText G" to device.
> 24. Device decrypts "CipherText G" using Device private key, resulting
> in "PlainText H".
> 25. Device pairs the session key ("PlainText H") with socket.
>
> Currently, this handshake happens when a new connection is created on
> any port / CPort (be it Control, GPIO, I2C, SPI, etc).
>
> While I understand that this security mechanism is not nearly as
> sophisticated as that of Thread, for example, it's fairly easy to
> implement locally for developers.
>
> However, we would ultimately like to support more than one method of
> authentication and encryption in Greybus. For the very basic method we
> implemented above, 5 additional message primitives were required:
>
> https://github.com/friedtco/gbridge/blob/feature/tcpip-ble-ipsp/pkauth.h#L32
>
> #define GB_PKAUTH_TYPE_VERSION 0x7a
> #define GB_PKAUTH_TYPE_PUBKEY 0x7b
> #define GB_PKAUTH_TYPE_CHALLENGE 0x7c
> #define GB_PKAUTH_TYPE_CHALLENGE_RESP 0x7d
> #define GB_PKAUTH_TYPE_SESSION_KEY 0x7e
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?
> 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.
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?
Same for crypto, why do you care about encrypting the datastream here?
What is the usecase?
thanks,
greg k-h
_______________________________________________
greybus-dev mailing list
greybus-dev@xxxxxxxxxxxxxxxx
https://lists.linaro.org/mailman/listinfo/greybus-dev
|