-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generalize/formalize message integrity checking options in MSG API #2467
Comments
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Nov 17, 2023
Adds two new APIs to the MSG module related to integrity: CFE_MSG_OriginationAction CFE_MSG_VerificationAction These should perform all calculations/updates on origination and all verifcation/checks at termination of the message path, respectively. The specific set of actions depends on how the user has implemented their particular MSG module. By default, the traditional CFE encapsulation sets a checksum on commands and a timestamp on TLM, and no verification at the receiver.
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Nov 17, 2023
Adds two new APIs to the MSG module related to integrity: CFE_MSG_OriginationAction CFE_MSG_VerificationAction These should perform all calculations/updates on origination and all verifcation/checks at termination of the message path, respectively. The specific set of actions depends on how the user has implemented their particular MSG module. By default, the traditional CFE encapsulation sets a checksum on commands and a timestamp on TLM, and no verification at the receiver.
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Nov 17, 2023
Adds two new APIs to the MSG module related to integrity: CFE_MSG_OriginationAction CFE_MSG_VerificationAction These should perform all calculations/updates on origination and all verifcation/checks at termination of the message path, respectively. The specific set of actions depends on how the user has implemented their particular MSG module. By default, the traditional CFE encapsulation sets a checksum on commands and a timestamp on TLM, and no verification at the receiver.
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Nov 17, 2023
Adds two new APIs to the MSG module related to integrity: CFE_MSG_OriginationAction CFE_MSG_VerificationAction These should perform all calculations/updates on origination and all verifcation/checks at termination of the message path, respectively. The specific set of actions depends on how the user has implemented their particular MSG module. By default, the traditional CFE encapsulation sets a checksum on commands and a timestamp on TLM, and no verification at the receiver.
2 tasks
This was referenced Oct 24, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
The MSG API has message integrity operations that are typically done on the origination side, as messages are generated:
There is also a complementary set on the recv side, e.g. to Validate Checksum.
However, because MSG is intended to be a user-configurable module, the user may want to expand on this baseline. For example, they may want to implement a checksum/crc on all messages, or timestamp on all messages, or something even further like a cryptographic HMAC signature.
The problem is, CFS apps are only (directly) invoking
CFE_MSG_SetTimestamp()
on outgoing TLM messages. There is basically an assumption that this is the only field that needs to be updated as messages are sent, but this assumption may not hold true if the user has added extra validation fields into their MSG implementation.Describe the solution you'd like
Add two new APIs to MSG to generalize message origination and validation:
CFE_Status_t CFE_MSG_OriginationAction(CFE_MSG_Message_t *MsgPtr, size_t BufferSize, bool *IsAcceptable);
CFE_Status_t CFE_MSG_VerificationAction(const CFE_MSG_Message_t *MsgPtr, size_t BufferSize, bool *IsAcceptable);
CFE_MSG_OriginationAction() would perform all integrity field updates associated with sending a message at the origination point, and likewise CFE_MSG_VerificationAction() would perform the inverse, to validate all message integrity fields at the reception point.
Additional context
Once this is in place, it can be integrated into
CFE_SB_TransmitBuffer()
such that CFS apps no longer need to call CFE_MSG_SetTimestamp() directly anymore. (although they still can/should for a while, as that gives backward compatibility, but it could be put behind the OMIT_DEPRECATED flag or something)Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: