Port aes cc310 driver #10907

RonEld · 2019-06-27T07:43:30Z

Description

Add support for CC310 AES driver,
returning MBEDTLS_ERR_PLATFORM_FEATURE_UNSUPPORTED for key size
other than 128 bits, and for AES modes not supported by the driver.
Use MBEDTLS_CTR_DRBG_USE_128_BIT_KEY.
Benchmark information, built with GCC_ARM:

 AES-CBC-128              :      15023 KB/s
  AES-CBC-192              :  Feature unsupported
  AES-CBC-256              :  Feature unsupported
  AES-CTR-128              :      15017 KB/s
  AES-CTR-192              :  Feature unsupported
  AES-CTR-256              :  Feature unsupported
  AES-GCM-128              :        232 KB/s
  AES-GCM-192              :  Feature unsupported
  AES-GCM-256              :  Feature unsupported
  AES-CMAC-128             :        531 KB/s
  AES-CMAC-192             :  Feature unsupported
  AES-CMAC-256             :  Feature unsupported

Tested also with the Mbed TLS On Target Tests on NRF52840_DK

Pull request type

[ ] Fix
[ ] Refactor
[x] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@ARMmbed/mbed-os-crypto

Release Notes

This is a target update, adding hw accelerated AES, however, it can also be considered as a breaking change, as it removes support for AES other than 128 bit keys.

40Grit · 2019-06-27T09:10:25Z

Please show effect on resource usage. Flash/ram

@trowbridgec @AGlass0fMilk

RonEld · 2019-06-27T10:26:05Z

Using the generated map file, I see the following changes:
RAM: no change
ROM: with the Cryptocell AES driver, 2432 bytes smaller than the sw AES implementation

RonEld · 2019-06-27T10:28:25Z

benchmark performance with the sw driver:

  AES-CBC-128              :        509 KB/s
  AES-CBC-192              :        439 KB/s
  AES-CBC-256              :        386 KB/s
  AES-CTR-128              :        513 KB/s
  AES-CTR-192              :        442 KB/s
  AES-CTR-256              :        388 KB/s
  AES-GCM-128              :        214 KB/s
  AES-GCM-192              :        200 KB/s
  AES-GCM-256              :        189 KB/s
  AES-CMAC-128             :        440 KB/s
  AES-CMAC-192             :        386 KB/s
  AES-CMAC-256             :        344 KB/s
  AES-CMAC-PRF-128         :        439 KB/s

40Grit · 2019-06-27T10:30:21Z

@maclobdell

ciarmcom · 2019-06-27T11:00:29Z

@RonEld, thank you for your changes.
@ARMmbed/mbed-os-crypto @ARMmbed/mbed-os-maintainers please review.

Add support for CC310 AES driver, returning `MBEDTLS_ERR_PLATFORM_FEATURE_UNSUPPORTED` for key size other than 128 bits, and for AES modes not supported by the driver. Use `MBEDTLS_CTR_DRBG_USE_128_BIT_KEY`.

RonEld · 2019-06-27T11:25:49Z

I amended the three files with the correct copyright year and updated the Arm brand name

Patater · 2019-06-28T10:42:47Z

features/cryptocell/FEATURE_CRYPTOCELL310/aes_alt.c

+}
+#if defined(MBEDTLS_CIPHER_MODE_XTS)
+
+void mbedtls_aes_xts_init( mbedtls_aes_xts_context *ctx ){}


If we don't define these, if someone attempts to use them, they'll get build failures. If we implement them doing nothing, that's a small waste of code space, but also could hide the unsupported nature until run-time. Maybe worth adding #error AES XTS is not supported with CC310 AES within this #if defined(MBEDTLS_CIPHER_MODE_XTS), instead of making empty functions.

Personally, I also prefer catching issues as soon as possible, e.g. at build time. However. this is according to our design, and in this specific case it may cause CI issues, when trying to set different configurations on different platforms

OK for now in this PR.

That's a problem in our CI, IMO. We shouldn't count it as a failure, nor attempt such an an invalid configuration, when a certain platform's ALT implementation can't do certain block modes.

Yes, this is why I added the FEATURE UNSUPPORTED PR

Patater · 2019-06-28T10:43:45Z

features/cryptocell/FEATURE_CRYPTOCELL310/aes_alt.c

+
+}
+
+int mbedtls_aes_setkey_dec( mbedtls_aes_context *ctx, const unsigned char *key,


This looks identical to mbedtls_aes_setkey_enc() other than one flag. Could we implement these functions by returning the result of a new function return mbedtls_aes_setkey(SASI_AES_DECRYPT)? It should save a bit of flash space, and be more readable.

Patater · 2019-06-28T10:47:17Z

features/cryptocell/FEATURE_CRYPTOCELL310/aes_alt.c

+        return( MBEDTLS_ERR_AES_BAD_INPUT_DATA );
+
+    return( CC_aes_cipher( ctx, mode, SASI_AES_MODE_ECB, 16, NULL, 0, input, output ) );
+


Style: Sometimes there is a newline here after return before }, and sometimes not. Be consistent at least. We prefer the no newline in this location style.

Patater · 2019-06-28T11:17:49Z

features/cryptocell/FEATURE_CRYPTOCELL310/aes_alt.c

+
+    if ( *nc_off )
+    {
+        /* handle corner case where we are resuming a previous encryption,


Does CC_aes_cipher not handle this corner case itself?

no. CC CTR implementation only supports where *nc_off is zero

What happens if it isn't? Incorrect computation? How do users of the CC API cope with this limitation ordinarily?

yes, incorrect computation. Users of CC, that are interested in *nc_off != 0 will need to do the same thing

Patater · 2019-06-28T11:19:40Z

features/cryptocell/FEATURE_CRYPTOCELL310/aes_alt.c

+    if( ( ( length % SASI_AES_BLOCK_SIZE_IN_BYTES ) != 0 ) && ret == 0 )
+    {
+        /* in case the length is not aligned, generate stream block for resuming
+         * increase nonce_block to the correct value*/


Could we fail with hardware unsupported or invalid parameter when alignment is not correct?

If not, maybe it's smaller in code size to copy the block to an aligned location, perform the hardware operation, and then copy back.

It's bad wording. It's not a matter of memory alignment. It's a matter of length which is a multiple of AES block size (16). This functionality generates the stream block for resuming on next call( if there is), for generating the first block on next block ( since *nc_off is not zero in this case)

I think that returning unsupported feature in this case will result in a major functionality decrease, on the expense of minor flash set back, IMHO

What's the use case exactly? Why this is a major functionality decrease? Don't users usually use AES with a length that's a multiple of the block length?

not for CTR.
CTR is streaming mode, which you can send any length of data, and pause the streaming in the middle, resume the streaming from same location, or any other arbitrary location

Seems odd that CC only lets you do CTR in multiples of the block length. Is that really the case? Doesn't that sort of defeat the purpose of streaming?

@Patater CTR mode is a stream cipher based on top of a block operation. From the user's perspective, partial inputs can have any byte length (even any bit length in theory). But under the hood, the operation involving the key works on 128 bits at a time (for a cipher with 128-bit blocks). If a call completes with a total input size that isn't a multiple of the block size, something in the stack has to remember the partial state. The hardware can't do this by itself (it would need to store the state of all ongoing calls). Either the hardware stores the partial state in an opaque form that the driver just keeps in memory, or the hardware works on 128 bits at a time and it's up to the driver to compensate. Usually, it's the latter: if the “hardware” is doing it, it means that some software layer deeper down is doing it.

@Patater In addition to what was mentioned by @gilles-peskine-arm CC supports any byte length as input, but it doesn't support byte offset.
As you can see from previous call to CC driver(line 284), the full length ( after reducing nc_off ), no matter what the length is. However, if the length is not a multiple of 16, then we need to calculate stream_block for next API call.

1. Make common function for setting key, which receives the direction as parameter. 2. Remove rediundant extra lines.

RonEld · 2019-07-01T10:39:42Z

@Patater I addressed your issues.
I modified the code according to the comments I agree with, and waiting for your feedback on other comments.

bulislaw · 2019-07-02T11:25:40Z

it can also be considered as a breaking change, as it removes support for AES other than 128 bit keys.

I don't exactly know how it used to work, but I don't want us to break people use cases. I'd much rather add it as an option for now and make it as default for 6.

RonEld · 2019-07-02T12:11:02Z

I don't exactly know how it used to work, but I don't want us to break people use cases. I'd much rather add it as an option for now and make it as default for 6.

Previously, AES 192 and AES 256 were supported by SW implementation. With this PR, a request for these key size modes( and some addition aes modes such as XTS and OFB ) will return an unsupported error.
The idea was to make it for the next major release, unless it is required for current minor release, in which case we should make it optional, by removing MBEDTLS_AES_ALT from mbedtls_device.h and users that want this feature will need to add this definition in mbed_app.json

Have the alternative aes undefined by default, in order not to break backwards compatability. `MBEDTLS_CTR_DRBG_USE_128_BIT_KEY` remains defined for better usability.

RonEld · 2019-07-08T15:34:13Z

I made the alternative aes optional. I will make a separate PR, updating the readme file

SeppoTakalo · 2019-07-17T11:49:11Z

@ARMmbed/mbed-os-crypto Please leave your review conclusions, + or -, Can this move forward, or does this require more work?

Patater · 2019-07-29T15:21:13Z

features/cryptocell/FEATURE_CRYPTOCELL310/aes_alt.c

+    if( ( ( length % SASI_AES_BLOCK_SIZE_IN_BYTES ) != 0 ) && ret == 0 )
+    {
+        /* in case the length is not aligned, generate stream block for resuming
+         * increase nonce_block to the correct value*/


Seems odd that CC only lets you do CTR in multiples of the block length. Is that really the case? Doesn't that sort of defeat the purpose of streaming?

Patater · 2019-07-29T15:21:23Z

features/cryptocell/FEATURE_CRYPTOCELL310/aes_alt.c

+}
+#if defined(MBEDTLS_CIPHER_MODE_XTS)
+
+void mbedtls_aes_xts_init( mbedtls_aes_xts_context *ctx ){}


Patater · 2019-07-29T15:21:33Z

features/cryptocell/FEATURE_CRYPTOCELL310/aes_alt.c

+static int CC_aes_setkey( mbedtls_aes_context *ctx, const unsigned char *key,
+                          unsigned int keybits, SaSiAesEncryptMode_t cipher_flag )
+{
+


Remove extra newline

Patater · 2019-07-29T15:21:39Z

features/cryptocell/FEATURE_CRYPTOCELL310/aes_alt.c

+    }
+
+    return ( 0 );
+


Remove extra newline

Patater · 2019-07-29T15:21:47Z

features/cryptocell/FEATURE_CRYPTOCELL310/aes_alt.c

+
+}
+int mbedtls_aes_setkey_enc( mbedtls_aes_context *ctx, const unsigned char *key,
+                    unsigned int keybits )


Align arguments

Patater · 2019-07-29T15:22:00Z

features/cryptocell/FEATURE_CRYPTOCELL310/aes_alt.c

+int mbedtls_aes_crypt_ecb( mbedtls_aes_context *ctx,
+                    int mode,
+                    const unsigned char input[16],
+                    unsigned char output[16] )


Align arguments

Patater · 2019-07-31T09:32:01Z

features/cryptocell/FEATURE_CRYPTOCELL310/mbedtls_device.h

@@ -22,6 +22,8 @@
 #define __MBEDTLS_DEVICE__

 #define MBEDTLS_PLATFORM_SETUP_TEARDOWN_ALT
+//#define MBEDTLS_AES_ALT
+#define MBEDTLS_CTR_DRBG_USE_128_BIT_KEY


I don't think we want to degrade the security of devices by default. Consider wrapping this setting in a ifdef, with a comment explaining why it's needed.

#if defined(MBEDTLS_AES_ALT) #define MBEDTLS_CTR_DRBG_USE_128_BIT_KEY #endif

AES-128 is acceptable as default security as long as there are less than about one quintillion devices (128-bit security, divide by two for the birthday bound) under ideal conditions (if there are side channels, it can be another matter, but more bits often doesn't help anyway). AES-256 gives a better security margin, but there's no reason to require it.

I agree, we don't want to degrade security, and perhaps as long as AES_ALT is not defined we shouldn't , however I decide to add it in order to have as less configurability as possible, for readability reasons. In addition, as mentioned by Gilles, the degrade doesn't have much effect.

1. Remove redundant extra lines. 2. Have the function parameters aligned. 3. Remove redundant white spaces.

RonEld · 2019-08-11T11:05:53Z

@Patater @gilles-peskine-arm I have fixes some style issues.
Please review.
I haven't changed according to #10907 (comment) as I don't think it's needed.

mbed-ci · 2019-08-20T11:21:25Z

Test run: FAILED

Summary: 2 of 11 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

jenkins-ci/mbed-os-ci_cloud-client-test
jenkins-ci/mbed-os-ci_exporter

0xc0170 · 2019-08-20T11:28:12Z

CI restarted

0xc0170 · 2019-08-23T08:21:28Z

Restarted CI (the last run did not complete neither reported here).

mbed-ci · 2019-08-23T09:38:45Z

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 2
Build artifacts

ciarmcom requested review from a team June 27, 2019 11:00

ciarmcom added the needs: review label Jun 27, 2019

Port aes cc310 driver

a58457d

Add support for CC310 AES driver, returning `MBEDTLS_ERR_PLATFORM_FEATURE_UNSUPPORTED` for key size other than 128 bits, and for AES modes not supported by the driver. Use `MBEDTLS_CTR_DRBG_USE_128_BIT_KEY`.

RonEld force-pushed the cc310_aes_port branch from 1a2f640 to a58457d Compare June 27, 2019 11:25

Patater reviewed Jun 28, 2019

View reviewed changes

Code improvements

50d7539

1. Make common function for setting key, which receives the direction as parameter. 2. Remove rediundant extra lines.

Make the alternative aes optional

a99ce83

Have the alternative aes undefined by default, in order not to break backwards compatability. `MBEDTLS_CTR_DRBG_USE_128_BIT_KEY` remains defined for better usability.

RonEld mentioned this pull request Jul 8, 2019

Explaining how to opt in modules #10991

Merged

Patater reviewed Jul 31, 2019

View reviewed changes

Style fixes

d09e3ef

1. Remove redundant extra lines. 2. Have the function parameters aligned. 3. Remove redundant white spaces.

Patater approved these changes Aug 19, 2019

View reviewed changes

0xc0170 added the release-version: 5.14.0-rc1 label Aug 20, 2019

0xc0170 approved these changes Aug 20, 2019

View reviewed changes

0xc0170 added needs: CI and removed needs: review labels Aug 20, 2019

0xc0170 added ready for merge and removed needs: CI labels Aug 23, 2019

0xc0170 merged commit b9a6251 into ARMmbed:master Aug 23, 2019

0xc0170 removed the ready for merge label Aug 23, 2019


		}

		int mbedtls_aes_setkey_dec( mbedtls_aes_context ctx, const unsigned char key,

		return( MBEDTLS_ERR_AES_BAD_INPUT_DATA );

		return( CC_aes_cipher( ctx, mode, SASI_AES_MODE_ECB, 16, NULL, 0, input, output ) );

Port aes cc310 driver #10907

Port aes cc310 driver #10907

Conversation

RonEld commented Jun 27, 2019 • edited Loading

Description

Pull request type

Reviewers

Release Notes

40Grit commented Jun 27, 2019 • edited Loading

RonEld commented Jun 27, 2019

RonEld commented Jun 27, 2019

40Grit commented Jun 27, 2019

ciarmcom commented Jun 27, 2019

RonEld commented Jun 27, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RonEld Jul 1, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RonEld commented Jul 1, 2019

bulislaw commented Jul 2, 2019

RonEld commented Jul 2, 2019

RonEld commented Jul 8, 2019

SeppoTakalo commented Jul 17, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RonEld commented Aug 11, 2019

mbed-ci commented Aug 20, 2019

0xc0170 commented Aug 20, 2019

0xc0170 commented Aug 23, 2019

mbed-ci commented Aug 23, 2019

RonEld commented Jun 27, 2019 •

edited

Loading

40Grit commented Jun 27, 2019 •

edited

Loading

RonEld Jul 1, 2019 •

edited

Loading