Enable secure channel on OSDP devices

[mistial-dev]

One of the questions for the UI is going to be how to handle reader desyncs (which are potentially a security issue).

I'd imagine that it makes sense for a reader that is unable to communicate due to key issues to flag an alert and get placed into an alert status. Repairing would ideally require intervention on the webui, which would reset it to the installer keys and/or turn off secure channel.

It's very important to not automatically re-key a reader.

[mistial-dev]

I had made some recommendations in the OSDP working group about how to handle this securely. There is an attack some devices are vulnerable to where panels will automatically rekey the reader if it shows back up with secure channel cleared.

If the key is deterministic and lacks something like a sequence counter, then it allows decryption of previously captured traffic, as well as future traffic.

With a sequence counter, it works only in the forward direction. Without knowing the old key, you essentially have to keep emulating a PD, rather than being able to do a MITM (as the old PD won't accept default keys, presumably).

Unfortunately, there are readers out there that have a very annoying "feature". If they go too long without communication (I'm talking like 30 seconds), they reset their device address to 0x01 (yes, not 0x00 like is the default on other readers), and their secure channel keys to default.

Handling graceful fallback without introducing security flaws is going to be fun.

[rsgmodelworks]

PSC (promscuous secure channel) is an ongoing problem. I just declare it a vulnerability if a PD is willing to drop back to the default key without intervention. It's also a vulnerability if the ACU presumes it should flip over to using the default key without operator intervention.. (I"m looking at you Software House, Axis, Mercury.) The ACU (e.g. Aporta) should in my opinion have an intervention-based workflow to rekey. It would also be nice if it detects a PD responding with NAK's indicating keying issues so the operator knows to invoke the (secured, careful) rekey sequence.

[bytedreamer]

Aporta won't drop back to default key once a non-default key has been set. Additionally, configuring a OSDP device to be in install mode (SCKB-D) will automatically trigger a key rotation to a random key.

[mistial-dev]

PSC (promscuous secure channel) is an ongoing problem. I just declare it a vulnerability if a PD is willing to drop back to the default key without intervention. It's also a vulnerability if the ACU presumes it should flip over to using the default key without operator intervention.. (I"m looking at you Software House, Axis, Mercury.) The ACU (e.g. Aporta) should in my opinion have an intervention-based workflow to rekey. It would also be nice if it detects a PD responding with NAK's indicating keying issues so the operator knows to invoke the (secured, careful) rekey sequence.

From a user-centric standpoint, it might be interesting to have a "DisabledReader" function where it uses default secure keys. Readers could end up in this situation by not accepting regular keys, or when removed from the panel (so they can be moved, recycled, etc.).

I could see a disabled reader having some unique alerting pattern to indicate that the reader is in that state. An odd beep or LED pattern, for example.

That way you still get security, but the reader isn't just sitting there disconnected. If the reader is going to default reset to insecure keys, then that should be the fallback.

Unfortunately, I have one reader (not going to name names) that after 30 seconds of non-communication, forcibly resets itself to default keys, 9600 baud, ID 1. It's insane.

[bytedreamer]

Here is how the first iteration of secure key management works on Aporta

• The operator configuring is not able to manually enter the security key. A unique random key is generated in the OSDP driver for each device and stored encrypted in SQLite DB.
• The operator has the option to set the OSDP device into install mode. This will initiate a routine that will automatically rotate to the unique random key once a secure session is established. It will continually attempt this key rotation on failures until successful. Aporta considers install mode with default key a temporary state.
• Once in secure mode with a unique secure key, the device must have matching keys. Aporta will no attempt to use the default key, unless the operator explicitly forces the device into install mode.
• A key rotation request will create a new random key.
• There is a field that stores the last key rotation. This can be used in the future for reporting and setting schedules to rotate keys based on policies.
• The OSDP driver configuration will display the online status of the secure session. An exclamation icon is displayed if the the keys don't match.
• In a related security checks, there is a ID match check as part of the initialization routine. If the OSDP device is replaced, it won't connect if there is a ID mismatch. The operator can clear existing OSDP device ID settings if needed.
• Future master passcode for key encryption can be done on hardware with a Secure Element. I'll look into using the Secure Element on the IONO Pi board.

[rsgmodelworks]

Sounds fine. In the case where aporta detects the device has changed it would be nice if there was a log message. I assume "changed" means the tuple (model,version,serial,firmware-version,oui) must be the same.