AES kernel abstraction layer

[Leon Schuermann]

Hello

Almost an entire year ago, as part of a student research project, a
fellow student and I implemented a small security token prototype based
on Tock. In light of the recent OpenSK announcement by Google [1], I've
dug up this project and was wondering whether some of the developments
could improve the TockOS project.

--

Around a purely safe Rust AES-128/256 implementation, we have thought of
an in-kernel AES abstraction layer. We are aware of the
symmetric_encryption HIL, but found it to be focused on hardware
implementations, and less flexible than desired.

Our efforts can be found here: [2]. These are in no way finished, but
should help explain the concepts.

The basic idea is to have a flexible layer, which can accomodate any
combination of supported AES key sizes and modes by the hardware, and
even support software implementations where the hardware does not
support the desired mode / key size.

This works by creating a strongly typed interface for AES keys, to be
used by the rest of the infrastructure.
Following that, two types of traits are used:

- "key traits" /^AES[0-9]*Engine$/
These traits provide methods for expanding the AES key, which is
required prior to any encryption or decryption operation. If a
hardware only supports a certain key length, the implementer may
choose to only implement for instance the "AES128Engine" trait. For
supporting all key sizes, it is sufficient to implement the
"AESEngine" trait.

- "block cipher mode traits" /^AES[A-Z]*Mode$/
If a hardware directly supports a given AES mode, the proper trait
can be directly implemented, providing methods for setting all
required parameters, such as initialisation vectors etc. However,
implementing the basic building block called "AESBlockEngine", all
other mode traits are implemented automatically.

For any given AES hardware or software implementation, it should be
sufficient to provide any combination of both key- and mode traits. This
implicitly describes the implementations' capabilities and can be used
to derive other possible modes.

This architecture appears to be fitting, as key expansion is AFAIK
generally independent of the chosen block cipher mode. Also, every mode
has different parameters and constraints, hence an individual trait per
mode. The abstraction should not incur a significant runtime cost,
although this is to be investigated.

A rudimentary usage of this infrastructure can be seen in [3], where a
(probably insecure and exclusively for research purposes) software
implementation of AES implements the basic "AESBlockEngine" and
"AESEngine".

Future improvements include terminology (trait names), more traits for
complex AES modes (currently only ECB is supported), a userspace driver
for each mode, support of existing HW implementations, and other changes
(i.e. make set_client() take an Option<>, etc.).

--

The primary advantage over the existing HIL is that _using_ this
architecture requires only the two well-defined key- and mode traits
respectively. It is not inspired by any hardware, but focuses on the
algorithms and their requirements/constraints instead.

I would love to hear feedback. If the general concepts make sense and
such an interface is appropriate for the Tock kernel, I'd be willing to
invest more time improving and mainlining this.

Thanks!

- Leon Schürmann

[1]: https://security.googleblog.com/2020/01/say-hello-to-opensk-fully-open-source.html
[2]: https://github.com/lschuermann/hsm-tock/blob/softaes/capsules/src/aes.rs
[3]: https://github.com/lschuermann/hsm-tock/blob/softaes/capsules/src/softaes/mod.rs

--
This email was composed and sent using free software.
emacs, notmuch, msmtp, qmail, linux, nixos, gnupg, ...

Proudly brought to you without php, outlook, and win32.

[Brad Campbell]

I think this is a great counterpoint to the symmetric_encryption HIL (and many HIL interfaces more generally) that helps with refining what the interface (or interfaces) should be. I think having a higher-level in-kernel interface for AES is a great idea, and something we could easily upstream as a capsule.

Also this suggests that having a more formal structure for kernel-specified interfaces that are not really HILs (like `hil/sensors::AmbientLight`) is increasingly becoming more useful.

- Brad

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/871rrffp4j.fsf%40silicon.is.currently.online.

[guill...@google.com]

I think a more generic HIL with various key size and modes of operations would be valuable!

The current HIL is very specific in which combinations it supports - as far as I understand it's mostly targeted at AES128-CCM which is used for the aes_ccm capsule, itself only used by ieee802154 radio as far as I can tell.

I'm not familiar with CCM nor ieee802154, but the traits seem quite specific, for example the parameters in the AES128CCM::crypt function are unclear to me (https://github.com/tock/tock/blob/master/kernel/src/hil/symmetric_encryption.rs#L122-L131).

Some collection of straightforward traits for block ciphers (not necessarily AES - although I don't expect much use cases of other block ciphers) of various keys/block sizes (again, the AES ones should be enough for a start), and modes of operations would be clearer.

It would also be easier then to e.g. expose symmetric encryption to userspace.

That way, userspace applications could benefit from hardware-accelerated/protected implementations (ultimately replacing things like https://github.com/google/OpenSK/tree/master/libraries/crypto).

The details are TBD of course (e.g. if an algorithm isn't supported by hardware, should the kernel provide fallback software implementations or should it leave that to applications?).

To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+unsubscribe@googlegroups.com.

[Leon Schuermann]

Hello,

"'guill...@google.com' via Tock Embedded OS Development Discussion"

<tock...@googlegroups.com> writes:
> It would also be easier then to e.g. expose symmetric encryption to
> userspace.
> That way, userspace applications could benefit from
> hardware-accelerated/protected implementations (ultimately replacing things
> like https://github.com/google/OpenSK/tree/master/libraries/crypto).
> The details are TBD of course (e.g. if an algorithm isn't supported by
> hardware, should the kernel provide fallback software implementations or
> should it leave that to applications?).

As this originated from a project quite similar to OpenSK, this was our
exact intention. The introduction of such an abstraction layer is only
the first step: following that, I'd like to provide software
implementations of good quality, as well as implementations for
supported hardware. Also, for each operation mode there should be a
driver with accompanying syscall interface.

Whether the kernel would actually load these drivers and what underlying
implementation to use would be specified in the board configuration.

Brad Campbell <bra...@gmail.com> writes:
> I think this is a great counterpoint to the symmetric_encryption HIL (and
> many HIL interfaces more generally) that helps with refining what the
> interface (or interfaces) should be. I think having a higher-level
> in-kernel interface for AES is a great idea, and something we could easily
> upstream as a capsule.

It's great to hear that other people think this could be beneficial to
mainline Tock. As the code is still very much in development, I will
prepare it for upstreaming with an _ETA of mid-March_ [I have my exams
to take care of first ;)].

We already have a rather clean, textbook implementation of AES in
software, using my development predecessor to the now mainlined
DynamicDeferredCall [1]. I'd also prepare this for mainlining. However,
we are in no way cryptography experts and assume this implementation to
be vulnerable to side-channel attacks. It may be valuable for
development and CI purposes.


Furthermore, we did similar work for hash algorithms and have software
kernel implementations of SHA1 and SHA2-224/256. Based on the interest
in AES, I guess these could be beneficial as well.

Best

- Leon

[1]: https://github.com/lschuermann/hsm-tock/blob/softaes/capsules/src/softaes/mod.rs

[Vadim Sukhomlinov]

I like idea of defining common abstractions for crypto algorithms, not just AES. Linux kernel Crypto API can be a good starting point. However, different devices may have different level of support - like special CPU instructions, basic AES acceleration in HW (just AES ECB mode), advanced AES with various modes of encryption (CTR, CBC, CFB, GCM, etc) as well as no acceleration at all. 

Most encryption modes can be used with other ciphers as well and may be or may be not accelerated in HW. Thus, it make sense to have several layers of abstraction - ECB (electronic code book) and modes of operations as software on top of it. Each mode of operation can be a capsule, implemented in software as a reference, and device-specific driver can replace it if hw acceleration is available on specific board/chip.

--
You received this message because you are subscribed to the Google Groups "Tock Embedded OS Development Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tock-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tock-dev/87wo8k92w1.fsf%40silicon.is.currently.online.

--

Regards,

Vadim Sukhomlinov