Handling of possible SHIP-ID mismatch by the stack

[randomdudebunchofnumbers]

api.ServiceInterface offers the possibility to mark a SKI as trusted by calling the method api.ServiceInterface.RegisterRemoteSKI. This method takes the SKI as sole parameter. The SKI comes from the user app's truststore, where it is stored together with the corresponding SHIP-ID. Upon a connection attempt the user app must compare the SHIP-ID saved in the truststore with the SHIP-ID it receives by the callback api.ServiceReaderInterface.ServiceShipIDUpdate. In case of a mismatch the user app must cancel the pairing process.

I'd like to propose to move this whole process into the stack. This would require a new method in api.ServiceInterface, e. g. RegisterRemoteDevice(ski string, shipID string). The initial SHIP-ID would come from []shipapi.RemoteService.Identifier as reported by api.ServiceReaderInterface.VisibleRemoteServicesUpdated. In case of a SHIP-ID mismatch, the stack would automatically cancel the pairing and update api.ConnectionStateDetail.ConnectionState with a new state ConnectionStateShipIDMismatch.

What do you think?

[DAMEK86]

Hey,
Do U have something in your mind about the trust store? I think the user needs full control over the store since the lib are not able to interact with hardware related stores as openssl providers like optee or tpm.
Or maybe it is not needed and the user likes to store it plain on disk or just hold it into the RAM for testing purposes.

[randomdudebunchofnumbers]

Hi,

I don't propose to replace the user app's trust store with an in-lib-truststore. So things like optee or tpm should still be handled by the user app. Trusted SKIs as well as the corresponding SHIP-IDs added by the proposed method api.ServiceInterface.RegisterRemoteDevice are stored within the stack at runtime and are kept in memory as long as the stack runs or the user app removes the trust by calling api.ServiceInterface.DisconnectSKI().

How truststore-data must be handled on the user-app-side is a question to the other experts here.

[DerAndereAndi]

I do like this idea a lot. We would need to define how the handling of different parameters should be done:

• Only SKI provided
• Only SHIP ID provided
• Both provided and both are found
• Both provided and only SHIP ID is found
• Both provided and only SKI is found

The process changes with SHIP 1.1. The recommendation there is to only match with the SHIP ID. The SKI can change there, when certificates get updated. Not mentioning this to include this in here, but to keep in mind and not design something that has to completely change again. In preparation to this the API could already take a list of SKIs for a service.

I'd also not use the word Device, as multiple EEBUS services can run on a device.

How about something like this?

RegisterRemoteService(ski []string, shipID string)