identity: ClientCertificateCredential with secret key in TPM?

Is your feature request related to a problem? Please describe.

The ClientCertificateCredential implementation requires that the application itself handle secret keying material, either as a string directly or indirectly as a file name that is, ultimately, opened and turned into a string internally. This, in turn, implies that the system on which the application is running has cleartext access to the secret material, at least while running, even if it’s stored under encryption at rest. This creates low-hanging risks for the secret key: it could be disclosed due to system misconfiguration (such as being accessible to a co-located service or user account) or due to bugs in the application (and/or its runtime).

Describe the solution you’d like

For (virtual) machines with (v)TPMs, HSMs, or other PKCS#11 providers, it would be a significant improvement to have the application not handle secret key material at all, only exchanging key identifiers and messages to be signed with the secure hardware. FWIW, Azure VMs generally support vTPMs (https://docs.microsoft.com/en-us/azure/virtual-machines/trusted-launch), as does HyperV (under which my motivating application is running).

Rather than implement this functionality directly in JS or linked native code, as identity authentication is performed only rarely, it may be simplest to offer a new Credential type that spawns an external program, writes the JWT to be signed to (and then closes) its stdin, and reads the signed response from its stdout. If spawning a program is too much overhead, then instead making a socket connection (to a SOCK_STREAM UNIX domain socket, especially) and using write(); shutdown(); read(); close() similarly, would also work fine.

This will probably require cooperation with msal, which looks like it ultimately outsources JWT work to the jsonwebtoken package?

I am unsure where, exactly, in this stack is the right intercept. In node-jsonwebtoken itself might be ideal, for broadest impact, but it looks like several places have their own ideas about the well-formedness of PEM-encoded keys, which will necessitate rework.

Describe alternatives you’ve considered

At the moment, because the secret keys are stored in files, they are roughly equivalent to client secrets for most threat models (nobody is realistically MITMing or decrypting our TLS session with Azure), and so we are using a ClientSecretCredential instead, with the secret held in a file available only to the application (and the root user), but this is less than ideal.

[KarishmaGhiya]

Hi @nwf-msr I will add code samples for using client assertion credential. We are planning to release it in July.

[nwf-msr]

With apologies, I haven’t had time to investigate. It seems like it should, but I haven’t jumped back into trying to make the TPM and nodejs play nicely together.