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,
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
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
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.
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
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
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
18. Device transmits "CipherText E" to Host.
19. Host decrypts "CipherText E" with Host private key, resulting in
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
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:
#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
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.
I would love to hear some ideas about this from whoever is interested.
Simplify the return expression.
Signed-off-by: Liu Shixin <liushixin2(a)huawei.com>
drivers/greybus/svc.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/greybus/svc.c b/drivers/greybus/svc.c
index ce7740ef449b..dca251172cd2 100644
@@ -1345,18 +1345,12 @@ struct gb_svc *gb_svc_create(struct gb_host_device *hd)
int gb_svc_add(struct gb_svc *svc)
- int ret;
* The SVC protocol is currently driven by the SVC, so the SVC device
* is added from the connection request handler when enough
* information has been received.
- ret = gb_connection_enable(svc->connection);
- if (ret)
- return ret;
- return 0;
+ return gb_connection_enable(svc->connection);
static void gb_svc_remove_modules(struct gb_svc *svc)
On Thu, Sep 03, 2020 at 09:57:42AM +0800, Ye Bin wrote:
> In gb_bootrom_get_firmware funtion fw maybe null, we must test it before
> use it.
No, fw will never be NULL when ret is zero so the current code is
Greg, please drop this one from your testing branch.
> Signed-off-by: Ye Bin <yebin10(a)huawei.com>
> drivers/staging/greybus/bootrom.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/drivers/staging/greybus/bootrom.c b/drivers/staging/greybus/bootrom.c
> index a8efb86de140..e1573a5febf0 100644
> --- a/drivers/staging/greybus/bootrom.c
> +++ b/drivers/staging/greybus/bootrom.c
> @@ -298,7 +298,7 @@ static int gb_bootrom_get_firmware(struct gb_operation *op)
> /* Refresh timeout */
> - if (!ret && (offset + size == fw->size))
> + if (!ret && fw && (offset + size == fw->size))
> next_request = NEXT_REQ_READY_TO_BOOT;
> next_request = NEXT_REQ_GET_FIRMWARE;
This Patch series is an update to the mikroBUS driver
RFC v1 Patch : https://lkml.org/lkml/2020/7/24/518 .
The mikrobus driver is updated to add mikrobus ports from device-tree
overlays, the debug interfaces for adding mikrobus ports through sysFS
is removed, and the driver considers the extended usage of mikrobus
port pins from their standard purposes.
v2: support for adding mikroBUS ports from DT overlays,
remove debug sysFS interface for adding mikrobus ports,
consider extended pin usage/deviations from mikrobus standard
use greybus CPort protocol enum instead of new protcol enums
Fix cases of wrong indendation, ignoring return values, freeing
allocated resources in case of errors and other style suggestions
in v1 review.
Vaishnav M A (3):
add mikrobus descriptors to greybus_manifest
mikroBUS driver for add-on boards on mikrobus ports
Add Device Tree Bindings for mikroBUS port
.../bindings/misc/linux,mikrobus.txt | 81 ++
MAINTAINERS | 6 +
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile | 1 +
drivers/misc/mikrobus/Kconfig | 16 +
drivers/misc/mikrobus/Makefile | 7 +
drivers/misc/mikrobus/mikrobus_core.c | 692 ++++++++++++++++++
drivers/misc/mikrobus/mikrobus_core.h | 191 +++++
drivers/misc/mikrobus/mikrobus_manifest.c | 444 +++++++++++
drivers/misc/mikrobus/mikrobus_manifest.h | 21 +
drivers/misc/mikrobus/mikrobus_port.c | 171 +++++
include/linux/greybus/greybus_manifest.h | 47 ++
12 files changed, 1678 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/linux,mikrobus.txt
create mode 100644 drivers/misc/mikrobus/Kconfig
create mode 100644 drivers/misc/mikrobus/Makefile
create mode 100644 drivers/misc/mikrobus/mikrobus_core.c
create mode 100644 drivers/misc/mikrobus/mikrobus_core.h
create mode 100644 drivers/misc/mikrobus/mikrobus_manifest.c
create mode 100644 drivers/misc/mikrobus/mikrobus_manifest.h
create mode 100644 drivers/misc/mikrobus/mikrobus_port.c