Behavior with a previously paired PD

[rsgmodelworks]

Could we talk about what should happen when a system (Aporta) and it's underlying ACU (osdp.net) encounter a PD that has been paired (configured with a private secure channel base key) with some other ACU. I think that the EAC (Aporta) should have some sort of event indication the operator can interpret to mean the reader is "not in install mode", to use common OSDP jargon. I think this means that when a PD emits "NAK (Encryption Required)" or when a SCS initiation sequence fails that there should be some sort of indication a human can use to know to go reset the PD. The PD should not respond to default-key secure channel connection requests after it has been paired. That's a vulnerability, right?

[mistial-dev]

It depends on your perspective. If the panel doesn't allow the reader to work, but the reader still talks to a MITM, the MITM will get the credential but the door won't open.

You could also just swap the reader for a bit, then swap it back to achieve much the same effect. Or even put a second reader at the door, with a post-it note on the real one saying "broken". People will tap one, then tap the other.