Pairing multiple devices?

[alex-miller-0]

I noticed your Keycard applet has a configurable number of pairing slots, which is hardcoded to 5 here. This would imply you want to allow multiple pairings for a given card.

Aside: We at GridPlus actually discovered issues with this (namely, a user who tries to pair with a new device when the card is at its limit would be unable to use the card since only a paired device can unpair). We have implemented an alternative that simply overwrites the first pairing slot whenever a pairing is made - this is better for our use case.

However, it seems like a user can only pair if a pairingSecret is loaded (used here) and the only way to load it is via the INIT command (here you can see the command getting blocked if pairingSecret has already been set).

Is this intentional? It seems odd to have the following both be true:

• 5 pairing slots
• Only the client that initializes the card can ever pair with it

Is there another way to allow pairing with multiple devices?

Aside: We are working on a "re-init" function (PR here), which allows a new device to load its own pairingSecret after the card has been initialized. Of course this means that the old pairing will be invalid, but this is not a problem for us (see earlier Aside).

[bitgamma]

That's not exactly how it works. The pairingSecret is a key generated from an externally known secret. In our case is the PBKDF2 output of a password, but this is not enforced by the card.

When the card is uniniitalized it has no credentials, so no PIN/PUK/Pairing password. In this state the card accepts a pairing-less one-shot SecureChannel to bring the credentials on-card. The credentials can then be changed by the user at any time (all of them). Changing the pairingSecret does not break existing pairings, because the actual pairing key is different for each pairing and stored individually.

You can pair up to 5 devices at the same time, with the user inserting the pairing password on each. The entire pairing mechanism is needed to counter active MITM attacks and that's why an off-band secret is needed. Overwriting a slot would lock-out a previously paired device, that's why we do not allow it. Although that could be an option if implemented in a way which requires user interaction/authentication.

There are scenarios where pairing is not desired, such as at a POS. We already provided a subset of commands which can be executed without pairing.

[alex-miller-0]

You can pair up to 5 devices at the same time, with the user inserting the pairing password on each

Okay yes, I was making the assumption that the pairing password was not something a normal user would ever interact with, but I do see how that's the mechanism to pair with multiple devices. What is the concern that led to that restriction? Our thinking is that we are encumbering spending with 1) physical ownership of the card, 2) a PIN, so pairing with a new device should not be too much of a concern. However, we have a secure interface and are not using NFC.

There are scenarios where pairing is not desired, such as at a POS. We already provided a subset of commands which can be executed without pairing.

Interesting. Which commands/pathways are you referring to? I don't see any way to get to a signature without pairing.

[bitgamma]

Please check https://status.im/keycard_api/sdk_pinless.html about this

[alex-miller-0]

Got it, thanks for clarifying!