Eric Biggers <ebiggers@xxxxxxxxxx> writes:
>
> Okay, so you admit that your "accelerator" is much slower than the CPU. So (1)
> does not apply.
>
> As for (2), it's not clear that applies here. Sure, your AES engine *by itself*
> may be more power-efficient than the AES instructions on the CPU. However,
> using the offload requires all the additional work associated with offloading
> the operation from the CPU. Since it's much slower, it will also cause the
> operation to be dragged out over much a longer period of time, keeping the
> system awake for longer when it could have gone into suspend earlier.
>
> Thus, using the "accelerator" could actually increase power usage.
>
> As for (3), a couple issues. First, you're just making an argument from
> generalities and are not claiming that it's actually true in this case. ARMv8
> CE instructions are in fact constant time.
>
> Sure, ARMv8 CE is generally not hardened against power analysis attacks. But
> you haven't actually claimed that your crypto engine is either.
1. AES/PKE engine inside DTHEv2 is DPA and EMA resistant.
>
> Second, these side channels, especially the ones other than timing, just aren't
> part of the threat model of most users.
2. Certification like SESIP, PSA and
IEC62443(being certified for CIP kernel- LFX [1])
All these have requirements for sidechannel attacks resistance.(check
lvl 3+)
Most of our users have these requirements and they don't even care about
performance in terms of speed.
>
> Meanwhile, a security issue we do have is that the hardware drivers tend not to
> be tested before the kernel is released, and often are released in a broken
> state where they don't even do the en/decryption correctly. Furthermore,
> unprivileged userspace programs may use AF_ALG to exploit buggy drivers.
3. We have devices in kerneCI and we have regular testing and engineers
working on acceleratprs internally too, we can be more careful about
that these drivers are going through prescribed testing for all
revisions.
We can reduce the prority for hw Accelerator by default if that's what
you're trying to imply and let users decide.
>
> It seems implausible that this patch is more helpful than harmful.
>
I don't understand why you call it harmful when it is providing the
security against side channel attacks.
If ARM itself prescribing to use crypto acclerators if they are
avialable, then it is beyond my understanding why would you push towards
using CE extensions.[3]
Are we not serious about the security than the performance itself?
For us,
Point 1 and 2 is at top priority and being a SOC vendor we want to make
sure that we provide all support that is needed by end customers for
their threat modeling.
For embedded systems, resource utilization is also very important,
I can use crypto accelerator and save CPU for other activities
But lets look at numbers, They are not 50x worse as you have mentioned in
earlier mail, they are just 2x bad. These a system with one core cpu
833Mhz and DTHEv2 at 400Mhz
root@am62lxx-evm:~# cryptsetup benchmark --cipher aes-cbc
cryptsetup benchmark --cipher aes-cbc
# Tests are approximate using memory only (no storage IO).
# Algorithm | Key | Encryption | Decryption
aes-cbc 256b 77.7 MiB/s 77.5 MiB/s
root@am62lxx-evm:~# modprobe -r dthev2
modprobe -r dthev2
root@am62lxx-evm:~# cryptsetup benchmark --cipher aes-cbc
cryptsetup benchmark --cipher aes-cbc
# Tests are approximate using memory only (no storage IO).
# Algorithm | Key | Encryption | Decryption
aes-cbc 256b 150.4 MiB/s 163.8 MiB/s
[1]https://dashboard.kernelci.org/hardware?hs=ti
[2]https://www.cip-project.org/about/security-iec-62443-4-2
[3]https://www.trustedfirmware.org/docs/Introduction_to_Physical_protection_for_MCU_developers_final.pdf
Cheers,
Kamlesh
