SDLS-EP Baseline: Key Management

[jlucas9]

No description provided.

[Donnie-Ice]

https://public.ccsds.org/Pubs/355x1b1.pdf (Page 3-1)

[rjbrown2]

Closes #44

[dccutrig]

For reference / my starting point on this: There are issues with the UTs in ut_ep_key_validation.c that involve memory corruption.

[Donnie-Ice]

According to @dccutrig, all Key Management unit tests are passing with no changes to the code. Can now resume work on this.

[dccutrig]

After much debate, we're jotting down our thoughts about how to proceed with this:

Note: We are able to create a buffer and gather the expected output.

• The ingest from TC_Process is the raw frame that TC is processing. This ingest is passed several levels and winds up passed into Crypto_Key_mgmt.c-> Crypto_Key_Verify ca. line 430.

• The core of the issue is we receive a static frame (Say, 40 bytes). The PDU Reply will be larger, it will have an encrypted challenge PLUS a Mac for each challenge, this causes a buffer overflow / stomps things.

• So, the output needs to be something besides the ingest. Crypto_key_verify needs a way to access / or generate / a TM_Frame to get this reply to the ground. Unfortunately, nominally, the aggregation and building of a frame is handled outside and above CryptoLib. This means that likely a semaphore/mutex is needed for CryptoLib to grab a clean TM_Frame, fill it with a reply, and send the reply. A mutex is needed because The Reply happens nominally as part of a CI library call, whereas Telemetry is generally created as part of a TO library call.

[dccutrig]

This is 99% resolved! We tracked the issue to a declared, but un-initialized local variable. During further testing and a re-write to get the sdls reply locally, it was causing garbage data to populate the IV and propagated through several function calls. There is a note / TODO about how to handle IV Generation for Key Verification - the old code assumed this happened in an SA with an active IV that could be used, but this is probably not what we want to do?