identity: ClientCertificateCredential with secret key in TPM?

[nwf-msr]

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.

[xirzec]

@mpodwysocki @KarishmaGhiya this sounds like an interesting scenario - can you help with guidance?

[nwf-msr]

A follow-up with a more specific avenue that may be worth considering. The OpenSSH agent protocol is widely spoken by cryptographic service providers, apparently fairly easy to speak from JS, as seen in https://github.com/131/ssh-agent-js for example, and capable of signing JWTs, as demonstrated by https://github.com/ptxmac/ssh-jwt. There's even support in OpenSSH's implementation for using PKCS#11 tokens and specifically the TPM as such: https://blog.ledger.com/ssh-with-tpm/ .

[KarishmaGhiya]

@nwf-msr We do not currently support protected certificate or key storage and we don't have any immediate plans to add support. But I will convert this issue to a feature request for a new credential type that creates the assertion with a callback to allow the application to sign the assertion.

We will be releasing a new GA for @azure/identity 2.1.0 with client assertion credential support. With that you could build and sign the assertion yourself for the hardware protected key. Let me know if you have any questions.