Second factor next to Master/RegularKey signature for authorizing transactions

[MarkusTeufelberger]

After reading a bit through the specs of U2F, FIDO2 and WebAuthn, I'm almost certain that it might be possible to:

• Attach a list of https://www.w3.org/TR/webauthn/#public-key-credential to an AccountRoot
• Add a few fields and flags (e.g. "2FA can be disabled with a n second lockdown period using a non-2FA transaction")
• Add a few transaction types related to this (add/remove/modify 2FA list)
• Add an https://www.w3.org/TR/webauthn/#authentication-assertion to transactions next to the signature(s) of the signing keypair(s)
• Have validators check the signature of the address AND the additional 2FA signature before applying a transaction

A usage scenario might be that it would then be possible to get my account in a state where:

• Every transaction requires me to also attach a signature from a YubiKey device next to the one from the actual wallet
• If I followed best practices (kept my MasterKey to myself and only handed my RegularKey to a wallet provider) I can deal with a loss/disclosure of the RegularKey without any impact on my side (the attacker can't sign Payment transactions with just the RegularKey, only try to disable 2FA after e.g. 60 days) giving me time to switch the RegularKey
• If I lose my 2FA device, I'm locked out of my account for a while, but will be able to regain access, depending on the implementation. I also could attach multiple devices, to be safe(r) against accidental loss.

I'm not sure if this is better done through multisig instead of natively supported, but some nicer features like a lockdown period are hard (impossible?) to implement that way though without external trust.

[nbougalis]

Interesting!

I'll have to read more about this, but my initial reaction is along the lines of your trailing comment:

I'm not sure if this is better done through multisig instead of natively supported, but some nicer features like a lockdown period are hard (impossible?) to implement that way though without external trust.

I too think that you're better off setting up multisigning. But I'll need to read more carefully to see if using WebAuthn may enable some cool use cases.

Depending on what you mean by "lockdown period" I think you can implement it without needing an external trust; just small improvements to XRP Ledger.

[smlu]

Just some side notes and random thoughts on this:

• Attach a list of https://www.w3.org/TR/webauthn/#public-key-credential to an AccountRoot
• Add a few fields and flags (e.g. "2FA can be disabled with a n second lockdown period using a non-2FA transaction")
• Add a few transaction types related to this (add/remove/modify 2FA list)

It should also be possible to extract an exact public key and generate a valid xrp address from the public key credential returned by an authenticator so no extra field would be needed. The challenge then remains where to store Credential ID which is needed to make a valid signature. Imo, It's probably best not to store it on chain.

Another problem with WebAuthn is that although the new underlying protocol CTAP2 supports EdDsa signature algorithm (it doesn't support secp256k1 yet) the old U2F now called CTAP1 which webauthn also wraps supports only EC P-256 (secp256r1). At this time, most of the webauthn ready devices are the U2F device which would not be compatible with xrp authentication algorithms. Then again, maybe it'd make sense to implement P-256 into xrpl. If anything, it makes possible to use SecureEnclave on iphone to sign xrp transactions.

-Add an https://www.w3.org/TR/webauthn/#authentication-assertion to transactions next to the signature(s) of the signing keypair(s) -Have validators check the signature of the address AND the additional 2FA signature before applying a transaction

Xrpl's signature verification procedure will have to be modified in a way to allow hash tx first and concatenate this hash with webauthn specific data (authenticatorData). Then use the resulting data to verify signature against. What data is signed by an authenticaticator device can be seen here, Figure 4.

A usage scenario might be that it would then be possible to get my account in a state where:

• Every transaction requires me to also attach a signature from a YubiKey device next to the one from the actual wallet
• If I followed best practices (kept my MasterKey to myself and only handed my RegularKey to a wallet provider) I can deal with a loss/disclosure of the RegularKey without any impact on my side (the attacker can't sign Payment transactions with just the RegularKey, only try to disable 2FA after e.g. 60 days) giving me time to switch the RegularKey
• If I lose my 2FA device, I'm locked out of my account for a while, but will be able to regain access, depending on the implementation. I also could attach multiple devices, to be safe(r) against accidental loss.

I'd argue this use case is interesting not only for WebAuth based devices but for any signature providing device. Imo the implementation should be generalized rather than fix specified for one protocol. Therefore, the easiest way would probably be to modify SignerList to allow weights based on transaction time delays. This will also require an implementation of delayed transaction which was discussed in #2945

[MarkusTeufelberger]

Generalizing/offering more options in multisign would also be a way I guess.

[JoelKatz]

Most of what you want can be achieved with a 2-of-3 multisig scheme. The wallet owner keeps two keys (one hot, one cold) and the system operator keeps one. This allows transactions to be executed with both the owner's hot key and the operator's key. If the operator fails, the owner can sign transactions with both the hot and cod keys. The operator, holding only one key, cannot execute a transaction without the owner.

[smlu]

I agree with @JoelKatz that in this case, probably multisig is the solution. What it doesn't give you is necessary time delay before owner can recover its account. Of course, if such setup is even required in the first place. I can't think of any good case where you would benifit from such setup but custodian account recovery. In this case, your account can be recovered with custodian keys after some time passed and custodians can't act against you before transaction isn't fully executed..

[carlhua]

Closing this - I think this can be achieved via other mechanisms.