Add Message Integrity attributes to UAttributes

[stevenhartley]

This issue will be used to track the changes to uAttributes to add secOC information to the UAttributes (mac, freshness value, and KSN).

Google Document tracking the requirements and implementation options: https://docs.google.com/document/d/1BU7glZ3ILPcvSWoFQvQG0qE5k-_thpYZyONoSOiEXxo/edit?usp=sharing

[RituPande]

The following optional attributes need to be added to uAttributes in a uMessage to ensure that uMessages shared between different uDevices are integrity protected.:
ksn: This is the two byte value identifying the Key Serial Number used to identify the key slot in SHE using which the message has been integrity protected.
fv: Freshness Value is a 8-byte value that provides the sequence number of the packet originating from a uDevice. The packet is accepted by the receiver if this value is within its acceptance window.
mac: This attribute contains the a 16-byte MAC created for following content: SecOCDataID || uMessage ( uAttributes + uPayload ). For obvious reasons, the mac attribute is not included in the MAC calculation.

Note:
1.SecOCDataId = secocMessageType (1-byte)|| Service ID( 2-bytes)|| Method/Event ID ( 2-bytes) for non-SD uMessages
2.SecOCDataId = secocMessageType || 0xFF 0xFF || 0x81 0x00 for SD messages
3. For the integrity verification to work correctly, the message serialization between two uDevices should be deterministic

[stevenhartley]

@RituPande ,
Ok I read the SecOC specifications to get an understanding of what SecOCDataID comes from. Why do we not use SecOCDataID like calculations outside of mechatronics domain as well in lieu of calculating MAC on the entire UMessage?

By email you mentioned that these attributes are for message protection between two uDevices. From that statement am I to believe that uEs (the sender and receiver) do not need to generate or validate the message integrity, only the streamers?
What should the system and/or uEs do when the validation fails?
How are the topics/messages declared to require these attributes appended to them or not?

There is a lot of missing information to be able to add anything to specifications (changes to the proto, examples in a language library like up-cpp, etc...).

[RituPande]

Ok I read the SecOC specifications to get an understanding of what SecOCDataID comes from. Why do we not use SecOCDataID like calculations outside of mechatronics domain as well in lieu of calculating MAC on the entire UMessage?

Ritu>> These are security requirements. To protect entire message

By email you mentioned that these attributes are for message protection between two uDevices. From that statement am I to believe that uEs (the sender and receiver) do not need to generate or validate the message integrity, only the streamers?
Ritu>> By requirement no. However, in my last discussion with zenoh they claimed that they cannot do it at their level

What should the system and/or uEs do when the validation fails?
Ritu>> Messages that fail validation should not be sent to uEs at all. That should be part of communication infrastructure and how they handle it
How are the topics/messages declared to require these attributes appended to them or not?

Ritu>> This was part of my document. But since you now won the uProtocol integration of SecOC, you can define that as you want

There is a lot of missing information to be able to add anything to specifications (changes to the proto, examples in a language library like up-cpp, etc...).

Ritu>> You would need to work with CYS team to find whatever info you need to integrate secoc with uProtocol

[stevenhartley]

Parking this topic while we wait for solution to be ironed out with CyS.