From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: nicolas.bouchinet@oss.cyber.gouv.fr
Cc: Luc Bonnafoux <luc.bonnafoux@ssi.gouv.fr>,
Alan Stern <stern@rowland.harvard.edu>,
Kannappan R <r.kannappan@intel.com>,
Sabyrzhan Tasbolatov <snovitoll@gmail.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Stefan Eichenberger <stefan.eichenberger@toradex.com>,
Thomas Gleixner <tglx@linutronix.de>,
Pawel Laszczak <pawell@cadence.com>, Ma Ke <make_ruc2021@163.com>,
Jeff Johnson <jeff.johnson@oss.qualcomm.com>,
Luc Bonnafoux <luc.bonnafoux@oss.cyber.gouv.fr>,
Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [RFC PATCH v2 0/4] Support for usb authentication
Date: Fri, 11 Jul 2025 13:08:51 +0200 [thread overview]
Message-ID: <2025071131-granular-twelve-ba5f@gregkh> (raw)
In-Reply-To: <20250711-usb_authentication-v2-0-2878690e6b6d@ssi.gouv.fr>
On Fri, Jul 11, 2025 at 10:41:21AM +0200, nicolas.bouchinet@oss.cyber.gouv.fr wrote:
> We have been working on the implementation of the USB authentication
> protocol in the kernel.
>
> You can find our work here https://github.com/ANSSI-FR/usb_authentication.
>
> It is still work in progress but we would like to start discussions
> about the implementation design and its possible integration to the
> Linux kernel.
>
> Best regards,
>
> Nicolas and Luc
>
> ---
> USB peripheral authentication
> =============================
>
> USB peripherals are an important attack vector in personal computers and
> pose a risk to the cyber security of companies and organizations.
>
> The USB foundation has published a standard to allow the authentication
> of USB peripherals ([1] and [2]). It defines a mechanism for the host to
> request credentials and issue an authentication challenge to USB-2 or
> USB-3 peripherals, either upon connection or later during the use of the
> peripheral.
>
> We currently envision the following use cases for USB authentication:
>
> - company networks where computers and peripherals can be privately
> controlled and administered;
> - USB cleaning or decontamination stations;
> - individuals who want to prevent unauthorized device plug-in into their
> machine.
>
> The implementation of this feature will obviously necessitate efforts
> from both the kernel community and peripherals vendors. We believe that
> providing an implementation of the host side of the protocol in the
> Linux kernel will encourage constructors to include this feature in
> their devices. On the other hand, we are working on implementing
> reference code for embedded devices, notably for Zephyr OS.
What about Linux as a device (i.e. the USB gadget system?)
If we have support for that here, then we can test both sides at the
same time on the same machine, making all of this much easier to
validate it works. Have you considered doing that work first instead of
doing it in zephyr in a totally different source tree where it makes it
very hard, if not impossible, for us to test this code ourselves?
thanks,
greg k-h
next prev parent reply other threads:[~2025-07-11 11:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-11 8:41 [RFC PATCH v2 0/4] Support for usb authentication nicolas.bouchinet
2025-07-11 8:41 ` [RFC PATCH v2 1/4] usb: core: Introduce netlink usb authentication policy engine nicolas.bouchinet
2025-07-11 8:41 ` [RFC PATCH v2 2/4] usb: core: Introduce usb authentication feature nicolas.bouchinet
2025-07-11 8:41 ` [RFC PATCH v2 3/4] usb: core: Plug the usb authentication capability nicolas.bouchinet
2025-07-11 8:41 ` [RFC PATCH v2 4/4] usb: core: Add sysctl to configure authentication timeouts nicolas.bouchinet
2025-07-11 11:08 ` Greg Kroah-Hartman [this message]
2025-07-13 15:25 ` [RFC PATCH v2 0/4] Support for usb authentication Greg Kroah-Hartman
2025-07-21 14:51 ` Nicolas Bouchinet
2025-07-25 8:54 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025071131-granular-twelve-ba5f@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=jeff.johnson@oss.qualcomm.com \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=luc.bonnafoux@oss.cyber.gouv.fr \
--cc=luc.bonnafoux@ssi.gouv.fr \
--cc=make_ruc2021@163.com \
--cc=nicolas.bouchinet@oss.cyber.gouv.fr \
--cc=nicolas.bouchinet@ssi.gouv.fr \
--cc=pawell@cadence.com \
--cc=r.kannappan@intel.com \
--cc=snovitoll@gmail.com \
--cc=stefan.eichenberger@toradex.com \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).