Source of CA's & Keys

[ryanviolet]

Hi - Can you confirm (if possible) where the keys have come from in assets.py?

i.e. are they likely to be revoked by Lutron, therefore blocking integration, or are they publicly published?

[eclair4151]

As far as i understand, most likely they were pulled from the mobile app or similar. These keys are essentially public keys, and used to prove authenticity of the devices and app, and used during the LAP connection button press to generate individual authentication credentials.

These key pairs are hardcoded into the firmware of the bridges, and into all shipping mobile apps. While Lutron could theoretically change these keys with a combined device firmware and app update. It would be a huge amount of work because everyone who has older bridges or versions of the mobile app would stop being able to connect to systems, so as far as I know, these keys are not going anywhere anytime soon, and even if they did, we would most likley have a long while to adapt to the changes.

[mdonoughe]

The CA certificates would be a huge hassle to change and would provide no benefit. The CA key (which we don't have) should be used at manufacture time to issue a certificate to every bridge and the CA certificate can be used to verify that bridge certificate. Theoretically, Lutron could create a service where bridges submit their current certificates and get new certificates signed by the new CA, but doing that would be difficult and would complicate the process of getting old bridges online. It'd be considerably more trouble for Lutron to implement than for third parties to update to. The only time it would make sense would be if somehow fake bridges were out there and either Lutron had a record of the public keys of every bridge ever shipped or had a way besides the bridge certificate to verify that the bridge was genuine and wanted to switch to a new CA which hadn't signed any fake device certificates.

They could change the LAP client key, but that would only prevent the pairing of new clients, and only until the clients were updated with the new key.

I wouldn't worry about this completely going away like how the SSH method went away previously. When you pair to the bridge this way, a unique credential is created linking your client to your bridge. With SSH, when the private keys got out, anybody could connect to any bridge they had network access to, but with LAP pairing you need physical access to the device to authorize the client first.

I think there are easier ways to break unsanctioned integrations, but making changes to break unsanctioned integrations likely breaks official integrations as well.