[Mobisys Tutorial] Thread Module Updates #4468
Conversation
seperate into: - hotp tutorial
- This copies checkpoint 5 of the hotp tutorial and includes this in the thread tutorial as the signed-sensor tutorial `encryption_oracle.rs`.
a0f77e5 to
0869d84
Compare
|
I was hoping we could make this a "regular" capsule. It seems generally like a reasonable tool. And once the tutorial happens no one wants to maintain tutorial-specific code. The more tutorial-only capsules we accumulate the more of a maintenance burden we have, or all the effort we put into creating these tutorials is gone because they don't work any more. Also, why is this called an "oracle"? I didn't understand this for the HOTP tutorial, but at that time it was last minute and bikeshedding the name wasn't appropriate. But if we are copying the name I would like to understand where it comes from. I thought conventionally an oracle in CS meant something that knew ground truth in a way that isn't feasible in a real system. But I don't think that definition applies here. |
This is a fair point and I do not disagree.
I was copying our ongoing / current naming convention from the hotp tutorial but do not have strong feelings as to what this is called. Perhaps a better path forward is to just use Since chkpt5 / hotp is already upstreamed, I propose we defer making this into a full fledged capsule to a separate PR (i.e. revert all changes in this PR besides those to the thread tutorial board main.rs). |
Good question, it's the term I thought was most fitting for this type of component at the time I was building it. 😅 Looking for a source to confirm this is the correct term, apart from finding out that a Google search query with "oracle" produces absolutely useless, database-related results, I found a couple lecture notes like the following: https://haiyangxc.github.io/hyxue/teaching/COMP6712-23/Lecture2.pdf While this is pretty much what our component does, it seems like this term is mostly used in "adverserial" settings, to reason about the security of a given cryptosystem. In our case, it's really more of an "encryption service" or "combined key-storage and cryptographic co-processor" (kind of like a simplified software version of the ATECC508A we already support). I don't find either of these terms more clear than "encryption oracle" per se, but I'm happy to change it. If we do so, I'd say we should do it consistently, everywhere, including in the HOTP tutorial. |
|
I think the HOTP capsule is appropriate as a tutorial capsule as the intent is to have participants write the capsule themselves. But if the capsule is just to be used, I'd rather have it as a normal capsule that could be reused in other contexts. Re naming, I'd be happy with a link to a wikipedia page (for people like me) explaining that the term of art in cryptography for an AES service is encryption oracle. But, an abstract notion of an oracle which can do some crypto operation is to me a poor naming match for a very specific service (e.g., run AES). It just seems out of place to me as a systems person; we wouldn't call a 15.4 driver "wireless_oracle.rs", but I think we could similarly talk about an adversary that has access to a wireless oracle that takes packet P_t(dest) and returns a boolean A. |
I think the key difference between what I would call an "oracle" and a more conventional "AES implementation" or "driver" is that in the "oracle" case, a user does not have access to the secret key material. The entire purposes behind the exercise in the HOTP tutorial is for it to resemble a Hardware Security Module (HSM) which holds some secret keys inaccessible to users (in our case in the kernel, but ideally within an actual proper HSM), but still allows them to perform cryptographic operations with this key material. Again, I'm totally fine renaming it to something else; in fact, it's probably a good idea. But calling it an "AES driver" etc. won't cut it, as it misses the above point. |
At the same time, a 15.4 driver doesn't have to expose certain parameters, like the channel being used, or the delay before the next TX slot, to still be called a 15.4 interface. Yet, like the key, the channel is critical for the protocol to actually work. But, it is still important that the name exposes that this is 15.4, as the packet structure depends on the specific protocol. I think in the abstract notion of an adversary model it might not matter what the underlying encryption algorithm is, and thus it is valuable to use a term which implies that the caller doesn't know, but the underlying implementation does. I think our case (for the upcoming tutorial) is different, and the caller does need to know this is AES. To me, with "aes.rs" versus "aes_service.rs", the "service" moniker denotes enough flexibility that maybe the caller isn't able to provide the key. Or maybe the caller is only able to select from a fixed set of keys. Exactly what the service does is implementation specific. But, that is just my interpretation, and I'm not pushing for that name necessarily. |
|
Also, let's revert the changes to the existing tutorial so we don't have to update the book. |
|
Re: naming of the "encryption oracle" capsule. Again, I think it's good if we found a better name for it. I apologize in advance, but maybe I can pull @pqcfox in for the bikeshedding? |
|
I like |
All of these (with preference for the first two, as they carry less ambiguity to me) are great. |
Pull Request Overview
This pull request updates the existing Thread tutorial to now include an encryption oracle capsule. These changes are backwards compatible with the existing Thread tutorial while exposing the needed capsule for the "signed sensor" tutorial module at MobiSys.
A few notes on what's included here:
capsules/extra/src/tutorialsto have separate directories for each tutorial (now that there is more than one)Although we could use
encryption_oracle_chkp5from the hotp tutorial (as this is what we are copying into a new directory), I think it makes more sense to have a copy so that the two tutorials can evolve freely without an arbitrary dependency. We have considered updating this to use AES128GCM rather than AES128CTR in which case having a separate copy would be necessary.Testing Strategy
This pull request was tested using the in progress "signed sensor data" tutorial module/app.
TODO or Help Wanted
N/A
Documentation Updated
/docs, or no updates are required.Formatting
make prepush.