Zephyr Authentication - ZAUTH #23465
Comments
deangereaux
changed the title
|
@deangereaux thanks for the submission! Could you please include a small paragraph about why the existing fast-pair spec is not a viable alternative? |
|
@carlescufi Added paragraph. I view GFPS as another possible authentication method provided by ZEBRA. Let me know if I missed any key points about GFPS. Thanks!! |
Not sure you need to complicate this as it seems the key establishment in BLE is okay. Since you are attempting to deal with the "I have the device" and "I'm authenticated" to use the device this seems to fill the "Out of Band" part of the section you referenced above. |
|
Maybe I'm missing a crucial paragraph, but it seems to me that this has little to do with Bluetooth specifically? I mean, it seems you want to decouple DTLS from its traditional UDP/IP dependency, which seems like a noble goal to me, but this all sounds equally applicable to for example direct serial communication, or NFC, or the homebrew 433 MHz Footooth protocol I just made up. Right? Why not just decouple it further - an easy-to-use, transport-agnostic authentication lib on one hand, and a Bluetooth-specific implementation on the other? |
|
The API is designed to be transport agnostic so yes in future versions there is no reason why ZEBRA shouldn’t be able to authenticate over a serial line or other transport. The ZEBRA design allows for different authentication methods and potentially different transports by adding a different transport specific thread, serial for example. However the transport and authentication are not cleanly decoupled as suggested, which has been previously suggested and is a very good idea. I’ll take hard look at implementing this separation. The reason Bluetooth is the initial focus is simple, it is the most common use case. This is actually why I started creating ZEBRA, I’ve been asked many times over the past 3 years to design and develop an authentication method for a phone to device via BLE Thanks for the feedback. |
carlescufi
added
RFC
|
API meeting: Dean proposes: |
|
dev-review: (Apr 16) - suggestion is put it under lib. Some comment about having this as a module:
|
|
For context: it appears these are the files changed/added to support this feature in its current form from https:/GoldenBitsSoftware/zephyr (there may be false positives, since a rebase had a lot of conflicts): Based on this it appears a module could work. It does not look like something I would expect to find in |
|
@pabigot Regarding the current state of: https:/GoldenBitsSoftware/zephyr. Yes I need to update, rebase, etc. |
|
Current status. |
|
API 2020-07-07: Moved from triage to in-progress. |
|
Current status: |
|
I've re-worked the majority of the code, still more to do but getting close to formally creating a PR. Here is the latest design document. |
deangereaux
changed the title
|
If this is not the right place to ask this question then please tell me where to ask. Please help me integrate Zephyr authentication- ZAUTH so that I can run sample bluetooth authentication code available. Parsing /home/chandranshu/zephyrproject/zephyr/Kconfig error: HAS_NRFX (defined at modules/Kconfig.nordic:187) is assigned in a configuration file, but is CMake Error at /home/chandranshu/zephyrproject/zephyr/cmake/kconfig.cmake:251 (message): -- Configuring incomplete, errors occurred! |
|
@Chandranshu9 ZAUTH is still a work in progress, so there will be bugs. All of the initial development has been with the Nordic nRF52840 Dev kit (see: https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF52840-DK). I'm hoping to finish and submit a formal PR by the end of December. |
Hello @deangereaux, Thanks for your quick response, Yes removing HAS_NRFX solved my issue, Now I am receiving some Kconfig warnings, The same warnings were also shown when I was running the test version of authentication. Please help me with this. I am eagerly waiting for the final version of your ZAUTH, it looks very promising. Parsing /home/chandranshu/zephyrproject/zephyr/Kconfig /home/chandranshu/zephyrproject/zephyr/zephyr-feature-auth_lib/samples/authentication/bluetooth/central_auth/prj.conf:6: warning: attempt to assign the value 'y' to the undefined symbol BT_GATT_DIS /home/chandranshu/zephyrproject/zephyr/zephyr-feature-auth_lib/samples/authentication/bluetooth/central_auth/prj.conf:22: warning: attempt to assign the value 'y' to the undefined symbol AUTH_LIB /home/chandranshu/zephyrproject/zephyr/zephyr-feature-auth_lib/samples/authentication/bluetooth/central_auth/prj.conf:23: warning: attempt to assign the value 'y' to the undefined symbol BT_XPORT /home/chandranshu/zephyrproject/zephyr/zephyr-feature-auth_lib/samples/authentication/bluetooth/central_auth/prj.conf:24: warning: attempt to assign the value 'y' to the undefined symbol AUTH_CHALLENGE_RESPONSE /home/chandranshu/zephyrproject/zephyr/zephyr-feature-auth_lib/samples/authentication/bluetooth/central_auth/prj.conf:27: warning: attempt to assign the value 'y' to the undefined symbol AUTH_CHALLENGE_RESPONSE /home/chandranshu/zephyrproject/zephyr/zephyr-feature-auth_lib/samples/authentication/bluetooth/central_auth/prj.conf:31: warning: attempt to assign the value '3' to the undefined symbol AUTH_LOG_LEVEL /home/chandranshu/zephyrproject/zephyr/zephyr-feature-auth_lib/samples/authentication/bluetooth/central_auth/prj.conf:55: warning: attempt to assign the value 'y' to the undefined symbol MBEDTLS_CIPHER_CBC_ENABLED error: Aborting due to Kconfig warnings CMake Error at /home/chandranshu/zephyrproject/zephyr/cmake/kconfig.cmake:251 (message): -- Configuring incomplete, errors occurred! |
|
@Chandranshu9 Not sure why you're getting these errors. I'll take a look later this week, in the mean time if you figure out what's causing these config errors, please let me know. |
|
@deangereaux This is because I am not able to integrate your ZAUTH with zephyrRTOS properly, Can you tell me how to integrate them both. |
|
@Chandranshu9 Let's move this conversation off this RFC doc. Please enter this info here as an issue: https:/GoldenBitsSoftware/zephyr/issues |
@deangereaux Sure, I have moved the issue. Please reply there. |
Origin: Original
New authentication library for authenticating devices, key features:
- Two auth methods, DTLS and Challenge-Response.
- Transport independent, initial support for serial and Bluetooth.
- Multiple authentication instances.
- Refer to ZAUTH RFC for more details:
zephyrproject-rtos#23465
Signed-off-by: Dean Gereaux <[email protected]>
|
I'm happy to announce, a PR has been submitted for ZAUTH |
Origin: Original
New authentication library for authenticating devices, key features:
- Two auth methods, DTLS and Challenge-Response.
- Transport independent, initial support for serial and Bluetooth.
- Multiple authentication instances.
- Refer to ZAUTH RFC for more details:
zephyrproject-rtos#23465
Signed-off-by: Dean Gereaux <[email protected]>
Origin: Original
New authentication library for authenticating devices, key features:
- Two auth methods, DTLS and Challenge-Response.
- Transport independent, initial support for serial and Bluetooth.
- Multiple authentication instances.
- Refer to ZAUTH RFC for more details:
zephyrproject-rtos#23465
Signed-off-by: Dean Gereaux <[email protected]>
|
Closing. |
ZAUTH - Zephyr Authentication
November 2020
More and more devices can now connect to each other, remote servers, and mobile devices. This added functionality provides end-users with better, more fully featured products, but at the very real risk of malicious attacks. The ability to authenticate peer communications, along with secure messaging, is how devices can protect themselves. Unfortunately, most RTOS systems do not have a framework or library to authenticate devices. The purpose of this ZAUTH proposal is to provide an easy to use framework to authenticate two peers over different transports such as Bluetooth and Serial. Zephyr is uniquely positioned with a large installed base and security as one of its key goals.
Some examples of device connectivity include:
Proposed Change
ZAUTH is a library to provide a consistent set of APIs to authenticate peer devices over an arbitrary transport such as Bluetooth or Serial. The authentication method and transport layer are selectable using the existing Zephyr KConfig process. The underlying transport is abstracted from the ZAUTH authentication methods using an opaque transport handle. This initial proposal supports Bluetooth and Serial (UART) transports along with Challenge-Response and DTLS authentication methods. ZAUTH is design to accommodate additional authentication methods and transports.
ZAUTH library code location is in the following directories from the Zephyr root:
Ease of use is an important goal of ZAUTH, most developers treat security as a headache. ZAUTH is easily integrated by using the following KConfig menu selections under “Additional libraries->Authentication library” as shown below.
Authentication API
The Authentication API is designed to abstract away the authentication method and transport. The calling application configures the ZAUTH library, starts the authentication process and monitors results via a status callback. The API is also designed to handle multiple concurrent authentication processes, for example If device is acting as a Bluetooth Central and Peripheral. An example of the API used is shown in the following code snippet.
Client Server Model
ZAUTH is designed as a client server model for the authentication message flow. The client initiates the authentication messaging sequence where the server responds. Depending on the authentication method chosen (Challenge-Response, DTLS, other), mutual authentication can be used to authenticate both sides of the connection. For some transports, this model maps nicely to the native transport model. Bluetooth is an example of this, a peripheral is in the server role and the central is in the client role. For Serial transports, the choice of which endpoint acts as the client or server is up to the application firmware.
Authentication Instances
Multiple authentication instances are possible concurrently authenticating connections over different communication links. For example, a Bluetooth central device could use different instances to authenticate different peripherals. Another example could be a HVAC controller with Bluetooth to communicate with mobile devices and a serial interface to control HVAC equipment. One instance would authenticate the mobile device, the second instance would authenticate the HVAC equipment.
Under the hood, an authentication Instance is a Zephyr thread and authentication method.
Authentication Methods
Two authentication methods are proposed, DTLS and simple Challenge-Response. However, the authentication architecture can support additional authentication methods in the future.
The proposed authentication is done at the application layer after connecting over the lower transport. This requires the firmware application to ignore or reject any messages until the authentication process has completed. This complicates the application firmware but does enable authentication independent of a vendor’s stack such as Bluetooth, TCP/IP, or serial. In addition, most embedded engineers have no desire to modify a vendor’s stack.
Secure Hardware Elements
Secure hardware elements provide a high level of security and cryptographic functionality at a low cost and power consumption. Ideal for resource constraint IoT devices. The key material and operations are performed in hardware, no keys are stored in the code. Common use cases include ECC or RSA key generation, signature verification, certificate storage, and key storage. Some examples of secure hardware are the Microchip ATECC608A, NXP SE050, and Infineon OPTIGA Trust M SLS32AIA. Each authentication method can potentially use secure hardware, however this initial version of ZAUTH will not support secure elements.
Detailed Design
The high-level diagram below shows the main ZAUTH components.
Authentication is performed in a separate thread started by the application. Each authentication method uses a dedicated thread to exchange authentication message with their peer. Adding additional authentication methods is done by creating a authentication instance. Messages are passed between the authentication thread and lower transport using an abstracted transport handle which maps to a Tx or Rx queue. The authentication threads are unaware of how messages are transferred. Optionally the lower transport can be configured to bypass the Tx queue and send the message directly to the lower transport, by passing the Tx queue. This is ideal for lower transports that handle their own message queueing.
An Authentication method is a defined message protocol between two peers. The message protocol contains details of the contents and the order of messages. The DTLS protocol is an example of a detailed authentication protocol. Messages are different sizes and depending on the lower transport, may not fit into a transports MTU size. For example, the default MTU for Bluetooth is 23 bytes versus the 512 byte minimum possible for DTLS record.
Authentication messages larger than the underlying transport MTU are fragmented; ZAUTH disassembles and re-assembles messages over the transport layer. For example, if a 267 byte message is send over a Bluetooth link with an MTU of 150, ZAUTH will break up the message into one 150 byte message and a second 117 byte fragments when sending. The receiving side will reassemble the fragments into the original 267 byte message before forwarding to the Rx queue. An important caveat is ZAUTH does not handle reordering of fragments, if fragment 2 arrives before fragment 1, the message is corrupted.
The diagram below shows how the Tx and Rx queues are used along with message fragmentation.
The Bluetooth Central Authentication sample (see samples/authentication/bluetooth/central_auth) provides a good example to drill deeper into the transport layer interface and how Bluetooth is “hooked up” to ZAUTH. The GREEN boxes are Bluetooth transport specific.
In auth_xp_bt_init() the Bluetooth connection (struct bt_conn) is added, along with the transport handle, to a connection using the struct auth_xport_connection_map
Transport Layer Interface
Transport layer details vary greatly, it does not make sense to create a one-size-fits-all transport API. ZAUTH separates the transport into transport independent and transport specific. For example, the details of the Bluetooth transport are in the auth_xport_bt.c file. This includes direct calls into the Zephyr Bluetooth stack. The transport common function, auth_xport_init(), calls the transport specific initialization function, passing the opaque transport handle (auth_xport_hdl_t) as an argument and transport specific parameters. The lower transport is responsible for mapping any transport specific variables to the transport handle. For example, the Bluetooth transport internally maps the transport handle to a Bluetooth connection handle, struct bt_conn.
The organization of the transport layers are show in the following diagram
Additional Topics
Comparison of Bluetooth Pairing and Authentication
Simply put, for commercial IoT applications pairing is not authentication. The Bluetooth version 5 specification does define three methods of authentication (Bluetooth spec version 5, Vol 2, Part F, Section 4.2.9): a) Numeric Comparison, b) Passkey, and c) Out of Band. All of these methods require a display on the device and a human in the loop. In all of these options, the user is manually performing the authentication. For commercial IoT applications, this is not an option. Imagine a commercial building where hundreds of light switches (the IoT devices) must be manually paired. Error prone and costly work.
Pairing establishes an encryption key for both parties (Central and Peripheral), which is different
from validating the identity of the remote peer. This is true for both Legacy and LE Secure pairing. While LE Secure pairing uses an ECC keypair and Diffie-Hellman Elliptic Curve to protect against eavesdropping, there is no capability to identify the remote peer.
GATT Authentication
GATT Authentication defined in the Bluetooth spec (Version 5, Vol 3, Part G, Section 8.1) is used to enable a per characteristic authentication using a shared key. It does not authenticate a Bluetooth peer (Central or Peripheral).
Google Fast Pair Service (GFPS)
This is a pairing method developed by Google to quickly pair consumer devices with and a phone and user’s account. See: https://developers.google.com/nearby/fast-pair/spec, for details. It is part of Google’s Nearby platform (see: https://developers.google.com/nearby). Authentication is accomplished by pre-shared keys provide by Google after registering your device (the thing you’re developing) with Google. While GFPS provides a great user experience, it has several drawbacks, specifically: a) requires a mobile phone, b) requires Google approval for your device, and c) licensing may not be consistent with Zephyr.
The text was updated successfully, but these errors were encountered: