Telemetry: Add an HMAC style authentication scheme to the telemetry system

未关闭
  • 哪里不对？
#136 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
30/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
冷清
技术栈
c
领域
embedded-iot, networking, security

调研方向

首先跟踪飞行计算机上的遥测消息生成、通过 LoRa 的传输，以及地面站/SDEC 路径中的接收和验证。查看 Flight-Computer-Firmware issue 191 中的替代方案，并在实现之前确定身份验证设计、密钥处理、对消息大小的影响以及无效消息的行为。完成的标准是，双方都集成了约定的安全措施，并且格式错误或未经身份验证的数据不会继续传播。

由索引模型根据 Issue 内容生成。

描述

enhancement

Requester: @ETSells

Describe the solution you'd like
The ground station currently provides no validation for the data it receives over LoRa. This is a security vulnerability. For the flight ecosystem, there is no impact on safety margins, so we have not prioritized it.

However, the new liquid feed system requires onboard flight data in order to function properly, so the criticality of this function will increase for that project. We need some security measure to provide an assurance that the received data is not maliciously malformed.

The flight computer has the highest design assurance and security assurance standards of any of SDR's projects, so we can safely consider it a trusted device. If the flight computer asserts that data is good, we can trust it. So, we need some method of determining that the device sending the data is the flight computer.

We can do this via some form of hashing scheme. Consider the following:

  1. A private key is generated in SDEC. This can be up to (256 bytes - lora_msg_size).
  2. That private key is uploaded to the flight computer and lives in the preset struct.
  3. When a telemetry message is generated, we take a buffer with the private key and the message, and then we hash over it using SHA-256.
  4. We can then append this hash to the generated message (either half of it (16 bytes) or the whole thing (32 bytes)). This brings our message length up to 64 bytes or 80 bytes, depending on how much of it we use.
  5. Continue the transmission process as normal
  6. The ground station receives the message, and if the CRC matches, it passes the whole thing including the hash to SDEC.
  7. On the other side, SDEC has a copy of the private key. It performs the same hash operation and compares its output to the signature.
    a. If the signature matches, then we have an assurance that both the message content didn't get mutated in transit and that the sender is within the trust boundary.
    b. If the signature matches, then either the message was corrupted in transit or sent outside the trust boundary. Either way, we discard the message and don't propogate the data through to displays.

Notably, since the message is fixed size, we shouldn't suffer from length extension attacks, which is the only known weakness of SHA-2. This does increase message size, which will reduce transmission speed.

Describe alternatives you've considered
See https://github.com/SunDevilRocketry/Flight-Computer-Firmware/issues/191.

Additional context
This is not an urgent feature that has to be worked in the upcoming release. The flight computer cannot be exploited as a result of the base vulnerability.

However, the New Liquids Feed System upgrades the criticality of the ground station and the data flow from it. As such, mitigation FC.NLFS.GS.3 requires the presence of some security measure on LoRa. Priority should increase as we get closer to NLFS completion.

Points of Contact
FC Rev 3 Project Lead / Telemetry & Security SME / NLFS PM & SQA: @ETSells

主要语言
C
星标
4
派生
2
平均合并
5 天 2 小时
30 天内合并 PR
6

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

SunDevilRocketry/mod 的其他 Issue

查看 SunDevilRocketry/mod 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。