On Sun, Feb 16, 2025 at 12:19:44PM +0800, Herbert Xu wrote: > On Mon, Feb 10, 2025 at 07:53:57PM +0100, Lukas Wunner wrote: > > > > https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/key.c > > > > https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/src/eap-tls.c > > > > > > Surely this doesn't use the private key part of the API, does it? > > > > It does use the private key part: > > > > It takes advantage of the kernel's Key Retention Service for EAP-TLS, > > which generally uses mutual authentication. E.g. clients authenticate > > against a wireless hotspot. Hence it does invoke KEYCTL_PKEY_SIGN and > > KEYCTL_PKEY_ENCRYPT (with private keys, obviously). > > Does it really? I grepped the whole iwd git tree and the only > use of private key functionality is to check that it matches > the public key, IOW it encrypts a piece of text and then decrypts > it again to check whether they match. > > It doesn't make use of any other private key functionality AFAICS. __eap_handle_request() [iwd src/eap.c] eap->method->handle_request() eap_tls_common_handle_request() [iwd src/eap-tls-common.c] l_tls_handle_rx() [ell ell/tls-record.c] tls_handle_ciphertext() tls_handle_plaintext() tls_handle_message() [ell ell/tls.c] tls_handle_handshake() tls_handle_server_hello_done() tls_send_certificate_verify() tls->pending.cipher_suite->signature->sign tls_rsa_sign() [ell ell/tls-suites.c] l_key_sign() [ell ell/key.c] eds_common() kernel_key_eds() syscall(__NR_keyctl, KEYCTL_PKEY_SIGN, ...) ... where tls_handle_server_hello_done() performs client authentication per RFC 8446 sec 4.6.2: "When the client has sent the "post_handshake_auth" extension (see Section 4.2.6), a server MAY request client authentication at any time after the handshake has completed by sending a CertificateRequest message. The client MUST respond with the appropriate Authentication messages (see Section 4.4). If the client chooses to authenticate, it MUST send Certificate, CertificateVerify, and Finished." https://datatracker.ietf.org/doc/html/rfc8446#section-4.6.2 I think the best option at this point isn't to aim for removal but to wait for Cloudflare to beat their out-of-tree implementation (which apparently isn't susceptible to side channel attacks) into shape so that it can be upstreamed. Thanks, Lukas
