capsules: Add support for AES GCM #3092

alistair23 · 2022-07-18T07:11:34Z

Pull Request Overview

This PR adds a new aes_gcm capsule. This capsule exposes AES-GCM support if the hardware doesn't actually have it.

We implement AES GCM using other supported AES operations and with a software implementation of ghash.

This is similar to the existing virtual_aes_ccm capsule, except without virtulisation.

AES-GCM is commonly used in TLS. It isn't commonly used in embedded systems, but it's still a good example I think.

Testing Strategy

Running the OpenTitan tests

TODO or Help Wanted

This PR adds an external dependency!

This PR adds a dependency on the ghash crate as part of Rust-crypto.

We are seeing more and more requirements for cryptographic operations in Tock, which means we are also seeing more and more software implementations of them.

Tock already has a SHA256 and CRC32 software implementation. It's not unreasonable that RSA becomes more common with the cryptographic app IDs as well.

I wanted to start the discussion about allowing Rust-crypto crates as capsules. Re-implementing a crypto library ourselves seem very risky, so if we do want software implementations Rust-crypto would be the way to go. I'm not convinced one way or the other, I just wanted to get some feedback on how people feel.

The Rust-crypto crates are well respected, have been audited and match the Tock software license

Documentation Updated

Updated the relevant files in /docs, or no updates are required.

Formatting

Ran make prepush.

phil-levis · 2022-08-01T23:22:23Z

boards/opentitan/src/main.rs

+static mut AES: Option<
+    &virtual_aes_gcm::VirtualAES128GCM<
+        'static,
+        virtual_aes_ccm::VirtualAES128CCM<'static, earlgrey::aes::Aes<'static>>,


Why is GCM building on top of CCM? They are different algorithms.

@alistair23 Can you explain your intended relationship between CCM and GCM?

phil-levis · 2022-08-01T23:26:13Z

Tock already has a SHA256 and CRC32 software implementation. It's not unreasonable that RSA becomes more common with the cryptographic app IDs as well.

I wanted to start the discussion about allowing Rust-crypto crates as capsules. Re-implementing a crypto library ourselves seem very risky, so if we do want software implementations Rust-crypto would be the way to go. I'm not convinced one way or the other, I just wanted to get some feedback on how people feel.

This has been discussed in the core call. The general consensus is that Tock should not have any cipher implementations used for confidentiality. E.g., there should not be Tock-specific implementations of AES or RSA. However, having simple software implementations of integrity primitives (e.g., hashes and CRCs) is OK. The expectation is that these are included to allow software testing without introducing dependencies.

The point you bring up, though, that some Tock boards are going to need software implementations of encryption/decryption and we should pull in crates to do so, is a good one. I will put it on the core call agenda.

alistair23 · 2022-08-02T03:33:12Z

This has been discussed in the core call. The general consensus is that Tock should not have any cipher implementations used for confidentiality. E.g., there should not be Tock-specific implementations of AES or RSA. However, having simple software implementations of integrity primitives (e.g., hashes and CRCs) is OK. The expectation is that these are included to allow software testing without introducing dependencies.

This PR only adds a software hash implementation. Does that mean you agree this should be added? Or do you mean Tock is ok with writing it's own implementations?

The point you bring up, though, that some Tock boards are going to need software implementations of encryption/decryption and we should pull in crates to do so, is a good one. I will put it on the core call agenda.

I was thinking a bit more about this.

Once we have verified AppIDs I could see a future where the default research loading mechanism is to try loading signed apps, with an allow fallback. This way we wouldn't break any users (if it's not signed we still load the app) but also provides a lot more test coverage on signed app loading. We can then update the tools to handle this as transparently as possible.

As well as that, there are lots of good Tock use cases that need crypto. LoRaWAN and other wireless communication stacks all use crypto by default.

These would only work if we had a default software crypto implementation though. So I think it's something worth considering

phil-levis · 2022-08-02T04:43:26Z

This PR only adds a software hash implementation. Does that mean you agree this should be added? Or do you mean Tock is ok with writing it's own implementations?

It does not mean that I agree it should be added. It means that it's something we need to discuss to explore all of the issues in play. Tock (so far) is OK writing its own software implementations of integrity primitives, such as hashes, checksums, and CRCs. However, that doesn't mean that it's the preferred thing to do.

I was thinking a bit more about this.

Once we have verified AppIDs I could see a future where the default research loading mechanism is to try loading signed apps, with an allow fallback. This way we wouldn't break any users (if it's not signed we still load the app) but also provides a lot more test coverage on signed app loading. We can then update the tools to handle this as transparently as possible.

This is already supported in the API. But the policies are more complex than this; there's a question of what signing keys are allowed. The current API requires the checker know something about the key, due to the exponent being implicit. We might make the exponent explicit, depending on requirements.

As well as that, there are lots of good Tock use cases that need crypto. LoRaWAN and other wireless communication stacks all use crypto by default.

True. Most chips (LoRa being an exception) have cryptographic support, though. The issue here is introducing external dependencies into the kernel for narrow use cases. We've resisted external dependencies for a long time, for simplicity. That doesn't mean the kernel won't ever use them, but for now it doesn't.

phil-levis · 2022-08-06T03:19:20Z

Notes from the OT call:

A virtual_aes_gcm capsule should virtualize an AES-GCM implementation for multiple clients. The current capsule should decompose the composition of AES-GCM from AES-CCM and virtualization into two separate capsules. The first is a translation that turns an AES implementation (and perhaps a GCM implementation) into AES-GCM. The second virtualizes AES-GCM.

The fact that the current AES-CCM virtualizer isn't decomposed this way and combines translation and virtualization shouldn't be taken as a reference design. The current code started with an early, 5-year-old AES-CCM implementation and extended the capsule to add virtualization.

phil-levis · 2022-09-08T22:31:25Z

@alistair23 Any progress on this?

alistair23 · 2022-09-09T07:40:32Z

I'm still waiting for an Ack or Nack about adding external crypto crates

phil-levis · 2022-10-03T16:03:03Z

@alistair23 I will bring it up on Friday just to be sure, but I am very confident that Tock will allow external (high quality, vetted) implementations of cryptographic primitives.

alistair23 · 2022-11-02T08:55:47Z

Ok, updated to remove the virtuliser part from this.

Once this is merged we can then look at adding a single AES virtuliser (while also removing the virtulisation from virtual_aes_ccm.rs)

alistair23 · 2023-04-17T01:00:13Z

Any more comments? I can rebase this if it will be accepted

3312: doc: Add ExternalDependencies.md r=hudson-ayers a=alistair23 ### Pull Request Overview This adds a document that describes some of the requirements of adding external crates. Once this is accepted the idea is then to add an external crate with #3092 ### Testing Strategy ### TODO or Help Wanted ### Documentation Updated - [X] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [X] Ran `make prepush`. Co-authored-by: Alistair Francis <alistair.francis@wdc.com> Co-authored-by: Brad Campbell <bradjc5@gmail.com> Co-authored-by: Leon Schuermann <leon@is.currently.online>

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>

alistair23 · 2023-05-15T06:57:20Z

I have rebased this now that the ExternalDependencies.md doc has been merged

phil-levis

Please add a comment explaining the reason behind the CCM/GCM composition (decorator pattern for API, to enable both), as well as a README with the cargo tree from the new crate. Then it's good to go.

Initial commit of a GCM capsule. This implements AES GCM support using an underlying AES CTR engine and the external GHash crate. Signed-off-by: Alistair Francis <alistair.francis@wdc.com>

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>

alistair23 · 2023-05-23T00:41:55Z

Done!

bradjc · 2023-06-07T22:35:16Z

bors r+

bors · 2023-06-07T23:02:01Z

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

github-actions bot added the WG-OpenTitan In the purview of the OpenTitan working group. label Jul 18, 2022

phil-levis self-assigned this Jul 29, 2022

phil-levis reviewed Aug 1, 2022

View reviewed changes

alistair23 mentioned this pull request Sep 12, 2022

RFC: External dependencies in the Tock kernel #3209

Closed

alistair23 force-pushed the alistair/aes-gcm branch from 6ffd9f9 to 5b986d4 Compare November 2, 2022 08:53

alistair23 marked this pull request as ready for review November 2, 2022 08:55

alistair23 mentioned this pull request Nov 3, 2022

doc: Add ExternalDependencies.md #3312

Merged

2 tasks

capsules: test: aes_gcm: Remove an empty test case

f80c25c

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>

alistair23 force-pushed the alistair/aes-gcm branch 2 times, most recently from 5f3b018 to 0264fbc Compare May 15, 2023 06:52

phil-levis previously approved these changes May 17, 2023

View reviewed changes

alistair23 added 3 commits May 23, 2023 10:41

capsules: symmetric_encryption: aes_gcm: Initial commit

24000fa

Initial commit of a GCM capsule. This implements AES GCM support using an underlying AES CTR engine and the external GHash crate. Signed-off-by: Alistair Francis <alistair.francis@wdc.com>

capsules: symmetric_encryption: aes: Add support for AES GCM

ec87156

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>

boards/opentitan: Add support for AES GCM

c155d68

Signed-off-by: Alistair Francis <alistair.francis@wdc.com>

alistair23 dismissed phil-levis’s stale review via c155d68 May 23, 2023 00:42

alistair23 force-pushed the alistair/aes-gcm branch from 0264fbc to c155d68 Compare May 23, 2023 00:42

bradjc approved these changes Jun 7, 2023

View reviewed changes

alistair23 closed this Jun 7, 2023

bors bot merged commit f5bd104 into tock:master Jun 7, 2023
15 checks passed

alistair23 deleted the alistair/aes-gcm branch June 7, 2023 23:36

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

capsules: Add support for AES GCM #3092

capsules: Add support for AES GCM #3092

alistair23 commented Jul 18, 2022 •

edited

Loading

phil-levis Aug 1, 2022

phil-levis Aug 3, 2022

phil-levis commented Aug 1, 2022

alistair23 commented Aug 2, 2022

phil-levis commented Aug 2, 2022

phil-levis commented Aug 6, 2022 •

edited

Loading

phil-levis commented Sep 8, 2022

alistair23 commented Sep 9, 2022

phil-levis commented Oct 3, 2022

alistair23 commented Nov 2, 2022

alistair23 commented Apr 17, 2023

alistair23 commented May 15, 2023

phil-levis left a comment

alistair23 commented May 23, 2023

bradjc commented Jun 7, 2023

bors bot commented Jun 7, 2023

capsules: Add support for AES GCM #3092

capsules: Add support for AES GCM #3092

Conversation

alistair23 commented Jul 18, 2022 • edited Loading

Pull Request Overview

Testing Strategy

TODO or Help Wanted

Documentation Updated

Formatting

phil-levis Aug 1, 2022

Choose a reason for hiding this comment

phil-levis Aug 3, 2022

Choose a reason for hiding this comment

phil-levis commented Aug 1, 2022

alistair23 commented Aug 2, 2022

phil-levis commented Aug 2, 2022

phil-levis commented Aug 6, 2022 • edited Loading

phil-levis commented Sep 8, 2022

alistair23 commented Sep 9, 2022

phil-levis commented Oct 3, 2022

alistair23 commented Nov 2, 2022

alistair23 commented Apr 17, 2023

alistair23 commented May 15, 2023

phil-levis left a comment

Choose a reason for hiding this comment

alistair23 commented May 23, 2023

bradjc commented Jun 7, 2023

bors bot commented Jun 7, 2023

alistair23 commented Jul 18, 2022 •

edited

Loading

phil-levis commented Aug 6, 2022 •

edited

Loading