Add threat model #2033
Add threat model #2033
Conversation
Signed-off-by: Douglas Stebila <dstebila@uwaterloo.ca>
| For certain algorithms and platforms, liboqs aims for "constant-time code" in the sense of no branching or memory accesses based on secret data. | ||
|
|
||
| - Algorithms: The [algorithm datasheets](https://github.com/open-quantum-safe/liboqs/blob/main/docs/algorithms/) indicate whether each algorithm and implementation aims for constant-time behaviour. These should be read in conjunction with the [issues/passes files for each algorithm's constant-time tests](https://github.com/open-quantum-safe/liboqs/tree/main/tests/constant_time). | ||
| - Platforms: We aim for constant-time behaviour on our [Tier 1 platforms](https://github.com/open-quantum-safe/liboqs/blob/main/PLATFORMS.md). |
There was a problem hiding this comment.
I'm a little hesitant to say that we aim for constant-time behaviour on all Tier 1 platforms, given that we only run constant-time tests on Linux / x86_64. There's a lot of aarch64 code that isn't constant-time tested, and we certainly don't run the CT tests on macOS. (Does Valgrind even work on macOS?) Maybe it would be best to say that we will respond to reports of CT issues on Tier 1 platforms.
I did actually try out the CT-time tests on the Arm runner late last year, and the results were OK: just a handful of reports on Falcon and McEliece that I haven't had time to pick through. Maybe this is a signal to take up that work again.
There was a problem hiding this comment.
If valgrind works on macOS I've never gotten it to work. 😓
There was a problem hiding this comment.
Good point. I was hoping to tie the threat model back to our supported platforms in some way, but I guess I didn't get it right. I guess yes, we could say that we will respond to reports of CT issues on Tier 1 platforms, and for all other tiers of platforms it is nice-to-have but not actively supported (or some other wording?).
There was a problem hiding this comment.
The PLATFORMS.md file has a † next to platforms on which constant-time tests are run—maybe we can refer to this in the threat model and make an effort to expand the list past x86_64 / Linux.
There was a problem hiding this comment.
This does raise an interesting conversation. Does it make sense that some tier 1 platforms be supported in different ways (in this case constant time checks) than others? Maybe it would be worth having a set of tier 0 platforms? Forgive me for not being super active so there might be other cases where we support some tier 1 platforms in different ways than that other tier 1 platforms, but having a tier 0 "we aim to support everything on this platform" might be a nice to have distinction.
There was a problem hiding this comment.
We actually discussed this in the PR for the PLATFORMS.md file: see #1605 (comment) and #1605 (comment).
Michael pointed out that you can go to an even higher tier than CT-tested (formally verified), which was one reason we didn't make an almighty Tier 0 for CT-tested platforms.
There was a problem hiding this comment.
Interesting discussion. But isn't this secondary (i.e., needs to be informed by) what is meant by "liboqs aims for"? Does OQS warrant it (if so, how?) or is it a "good intention" only (everyone "aims" for being a good person, say) without concrete things someone can rely on (and that OQS has to pay for in terms of effort)?
There was a problem hiding this comment.
That's a good point Michael. For a security policy I think "We aim for" means we have actively deployed something that we think achieves the thing we are aiming for, but it covers us from issues where there may be a testing/implementation/whatever bug.
There was a problem hiding this comment.
Well, "covering" OQS is all well and good -- so I understand why the formulation is a bit "wobbly". So let me try again: Wouldn't it be good from the perspective of a user to know what this assertion exactly means? Is OQS indeed warranting (to the best of its knowledge) that algorithms marked "constant time" are such? Or is it really that OQS only and exactly asserts "no branching or memory accesses based on secret data" exists (but no instruction-level execution time independence based on secret data, say)? I guess what I'm trying to say is: If OQS "aims for" some property, should that be defined --together with the methods it asserts it-- to some more detail?
There was a problem hiding this comment.
Regarding the "wobbly" formulation of "aims for": yes, that could be improved. I guess a more direct way of saying it would be something like:
The threat model for algorithms/implementations listed as "constant-time" on the algorithm data sheets, on the subset of Tier 1 platforms indicated as "constant-time tested", includes "constant-time" behaviour.
As discussed in the 2024-12-05 TSC meeting, we want to update our SECURITY.md file to mention our threat model. I have based our threat model on the one in the OpenSSL security policy.
Feedback and discussion welcome.