Closed rtadros125 closed 4 years ago
@rod-chapman I will un-assign you from the TLS ticket and move it back to the backlog. I will be moving other performers to work on the new FreeRTOSmirror and doing the mbdeTLS work (and maybe https). Since both of these are super clear pre-requisites to any work you'd do on top, and the OTA seems a non-trivial task. Sounds good?
@rtadros-Galois @kiniry - please take a look at https://github.com/DARPA-SSITH-Demonstrators/SSITH-FETT-Docs/blob/ota_design/applications/freertos_ota_design.md
This is my current "strawman" for how the OTA service will work. Happy to talk about it later if you like, or we can collect comments in a PR...
@abakst - you should probably have a look at the link above too...
@rod-chapman Thanks a lot for the document. I have the following questions:
7&8. Now I got what was confusing me. I didn't know about TFTP; I thought it's the same as FTP. Huh, hmmmmm, I am not sure if I like this. My two concerns are: 1. FreeRTOS networking is not great, I mean the drivers are not that reliable, so I am not sure if relying on UDP makes sense tbh. It might affect our target robustness in terms of basic-functionality. 2. This can be trivially spoofed. I am not sure how I feel about having a bug bounty contest where we ask the hackers to attack our OTA, and then we send our firmwares over UDP. What am I missing here?
7&8. Now I got what was confusing me. I didn't know about TFTP; I thought it's the same as FTP. Huh, hmmmmm, I am not sure if I like this. My two concerns are: 1. FreeRTOS networking is not great, I mean the drivers are not that reliable, so I am not sure if relying on UDP makes sense tbh. It might affect our target robustness in terms of basic-functionality.
UDP vs TCP won't make a difference here. The drivers are a bit unreliable, but I've never seen them corrupt data, just decide to not send/receive packets. TFTP has its own retry mechanism on top of UDP so dropping packets can be tolerated just like TCP, but will nonetheless slow it down.
- This can be trivially spoofed. I am not sure how I feel about having a bug bounty contest where we ask the hackers to attack our OTA, and then we send our firmwares over UDP. What am I missing here?
You just have to not do the crypto at the transport layer. Your OTA receives data unauthenticated and in the clear, and the payload itself that goes over TFTP should be signed. Just like what happens when you download firmware updates from manufacturers' websites and then separately upload them to your home router via its web interface (or at least used to, maybe not these days).
I agree. Thanks for the clarification. Then number (6) becomes critical here. We have to do the crypto part in a perfect way if we're gonna leave the transport layer wide open. Right?
I don't have additional points to make on the points that have been discussed, it seems like most of those have been resolved and the plan looks reasonable to me.
My feeling is that confidentiality of the update blob is not critical for the purposes of FETT, though discovering an information leak that could leak the contents of the payload might be interesting. But in that case it would be just as interesting if the payload were pushed unencrypted (as I understand it, the network itself is not a target, so a "win" would be reading confidential data from FreeRTOS memory)
Thanks for the comments everyone.
Point 4: Perhaps "server" is the wrong word - our FETT target will be running a service that waits for, accepts, and services TFTP requests from the bastion host. This is playing the role of the "tftpd" binary on a traditional system. The attackers use "tftp" on the bastion host to initiate (i.e. "push") a file to be transferred to the target.
Point 6. The "payload" here is really just a text file (or perhaps HTML), not a commercially sensitive firmware binary. Besides, the attackers will be trying to inject their own payloads into the target (e.g. an HTML file that says "You have been hacked.") so there's no loss in it not being encrypted since the attackers already know what it says! The scenario where confidentiality does matter is where "we" (playing the role of the IoT device manufacturer) want to ship some super secret new binary code to our devices in the field, and we don't want anyone intercepting it and being able to reverse engineer it... but... that's not a win condition for this competition... (at least, I have decided that it's not... I guess Joe could overrule and say that it is...)
Encrypting the payload is not really a problem. The big problem is how you get the secret symmetric key into the target and keep it secret. This is a big problem, unless you have a proper HSM with secure key storage facility. According to Reuben, our HSM doesn't have that... :-(
So.. I can see 2 win scenarios:
WS1: Attacker crafts a file to upload, or perhaps write a malicious TFTP client that exploits some vulnerability in FreeRTOS or the UDP/IP stack, or in our own OTA code to brick the target. Denial of service = win!
WS1: Attacker somehow manages (as above) to bypass the OTA signature verification and gets a payload file "nasty.txt" stored onto the FAT filesystem. The attacker then fires up a web browser, connects to the target via HTTPS and asks the server for https://target/nasty.txt and voila is able to prove that they hacked us.
PS... I hope to talk to Dylan H soon to confirm the exact capabilities of the hardware HSM. Reuben said it can do SHA2-384 and AES, but NOT any elliptic curve and/or ECDSA stuff. As I said, Reuben also reports no secure key storage.
My plan is to start with implementation of all that purely in software, then move over to use the HSM as and when it (and its software drivers) become available.
Another benefit of that approach is that I should be able to prototype the whole thing on a vanilla Linux box, which I like.
Ok, I think we have a plan then (this sentence is giving me a deja vu):
Todo list (OTA pre-requisites):
We're almost at sprint#1 midpoint, and we're still going back and forth with this. We need to make all the decisions soon.