Using a second device as a decryption source. Like 2FA but not for authentication

Question

I don't have a completely clear idea about this so apologies if the question is a bit unclear. 2 factor authentication is well known. We see it as involving a second device in order to answer a yes/no question. It is based on the second device being trusted by the requestor. What I'd like is a method to use a second device to decrypt a secret, or provide some indication that a challenge can have a response that is equivalent.

So an example might be a server containing encrypted data and some script invoked that makes a call to another device saying 'decrypt this' which is then used to decrypt the data on the original server. Does this make sense? I've tried thinking about it in terms of the yes/no of authentication, like get the 'yes' it's ok to decrypt back from the second device but the actual decryption secret is on the original server and thus vulnerable to compromise; the second device is not essential as far as I can think it.

Does such an app or service exist to solve this? Do we know if adapting 2FA to provide this has been done or is in fact possible?

Many thanks.

Answer 1

2 factor authentication is well known. We see it as involving a second device in order to answer a yes/no question. It is based on the second device being trusted by the requestor.

While this might look like in some cases as a simple yes/no on the outside, it is not. The server cannot blindly trust arbitrary devices answering with yes.

What I'd like is a method to use a second device to decrypt a secret, or provide some indication that a challenge can have a response that is equivalent.

That's how established 2FA methods (or strong single factors) like FIDO2, WebAuthn, smartcards, client certificates (which might be hardware backed)... work internally. They rely on asymmetric cryptography and basically proof to the server by signing a challenge with their private key, that they have access to this private key. The server can then verify the response (the signed challenge) by validating it with the matching public key, which the server either knows through initial registration or which is backed by some public key infrastructure (PKI).

Other methods like TOTP and HOTP involve a shared secret with the server (shared within enrollment of the authentication factor). The challenge here is not explicitly given by the server but derived from the time (TOTP) or some counter shared between client and server (HOTP).