crypto: policy for integration of experimental crypto

[emmanuelsearch]

Description

RIOT is a good candidate for experimenting with new crypto algorithms and new crypto libraries/implementations that may be in scope for low-end IoT devices.

However, we neither have a clear policy, nor specific mechanisms to flag experimental crypto modules considered less mature compared to other crypto modules which should be recommended in practice for production-ready code. Until now, our policy was: if there is an interesting experimental package PR which passes our basic quality tests, we merge it (recent examples: qdsa, libhydrogen, hacl).

As brought up with other PRs currently in the pipline (e.g. see pqm4) the question is if, and how we should change our policy.

Useful links

pqm4, qdsa, libhydrogen, hacl

[emmanuelsearch]

Discussing offline with @kaspar030 one idea that came up was: we could consider issuing (and maintaining) a set of recommendations and best practice as to what crypto is currently recommended for use with RIOT. To issue such a document, we could take advice from a set of well-known specialists we are in close contact with (there are a few) and base ourselves on reports such as ECRYPT recommendations e.g. see Table 4.6 for key size recommendations etc.

[olegart]

Such flagging can (and will) be misleading as it implies that other cryptographic algorithms implemented in RIOT (not flagged as experimental) are safe to use in production.

They are not.

I'm not a cryptography expert but even I can see that RIOT standard cryptographic functions are not hardened against common attacks. AES uses generic algorithm, PRNG seed is the same on every boot, etc.

[emmanuelsearch]

@olegart there is work ahead, agreed. Question is: what is RIOT standard cryptography? This is not defined anywhere. Hence what the suggestion to work towards defining that.

Side question: if I am not mistaken you use RIOT in production? What crypto do you use?

[olegart]

@emmanuelsearch we are using AES128 (RIOT's implementation but with reduced flash footprint, #10037) and PRNG seeded with TRNG based on radio channel noise (and I'm thinking of implementing jitter-based TRNG for cases when radio is not here).

Still, that doesn't mean this AES implemenation has no flaws (it has), but we see it as suitable for our case.

Regarding future work: 1) I don't think hardening or even proper evaluation of RIOT's embedded crypto functions will ever happen. Hardening against side-channel attacks is extremely complicated, and proper audit costs some money and, actually, RIOT is not ready for it.

2) Some measures should be taken, though — seeding PRNG with TRNG value wherever possible, better SRAM PUF implementation, etc. As for now, PRNG default seeding with constant value (even SRAM PUF hash must be considered constant for a number of reasons) is a joke.

3) Words must be chosen very carefully. Marking some crypto as experimental must not imply that some other crypto is in any way production ready. In fact, here we have 3 types of crypto functions:

• experimental crypto — was not tested well enough to be considered secure against direct attacks. Not recommended for production use.

• reliable crypto — no known direct attack exists, but specific implementation may be prone to side-channel attacks depending on usage scenarios and other details. Recommended for production use but in no way guaranteed to be absolutely secure.

• unreliable crypto — there's known direct attack against it. Not recommended for production use except for historical/compatibility reasons.

For direct attack only encrypted data are needed. In case of side-channel attack, physical access to device and ability to perform some measurements and/or manipulations is required, so in most cases susceptibility to side-channel attacks may be considered harmless.

[jowlo]

I agree with @olegart that (P/T)RNG improvements are most pressing, as otherwise any crypto algorithms/schemes relying on randomness will be flawed from the start. However, looking at To Do - Issues in Security this is being worked on.

One could argue that if some sort of warning is issued for non-reliable crypto, there should also be one for RNG use without a proper source of randomness.

I also don't see any hardening against power or EM side channels happening anytime soon. However, for non-constant time implementations - which are at least present in packages, e.g. in tinydtls's ecc implementation - no hardware access is necessary and remote timing attacks (at least in theory) are possible. I would expect implementations falling into the reliable category to provide protection against remote exploits.

If this is supposed to be applied to all RIOT code including packages, even grouping existing packages into any of these three categories would be quite an effort.

I do think, experimental and unreliable would be sensible categories, but reliable is pretty hard to define.

[olegart]

However, looking at To Do - Issues in Security this is being worked on

No, actually it isn't. There are some forgotten PRs from 2015-2016, that's it.

In my opinion, there's only one reputable generic entropy source — jitter between independent clocks, it can be implemented on most modern CPUs (at least most Cortexes have 1 to 3 internal high-speed clocks and internal low-speed RTC/RTT clock, so it can be done irregardless of hardware configuration).

By default, PRNG should look for this kind of source or HWRNG source, if these are not available, compile-time warning should be issued.

no hardware access is necessary and remote timing attacks (at least in theory) are possible

BTW, I'm not sure if even AES is constant-time here. Probably not.

[waehlisch]

2. Some measures should be taken, though — seeding PRNG with TRNG value wherever possible, better SRAM PUF implementation, etc. As for now, PRNG default seeding with constant value (even SRAM PUF hash must be considered constant for a number of reasons) is a joke.

This is something @PeterKietzmann is working on. Preliminary results are available here http://summit.riot-os.org/2018/wp-content/uploads/sites/10/2018/09/3_2-Peter-Kietzmann-Crypto-Fundamentals.pdf

[olegart]

@waehlisch PUF is not good enough for PRNG seeding, as PUF can only be obtained after power-off for 5 seconds or more, and we need to re-seed PRNG with the new TRNG value after each reboot.

SRAM PUF is much more usable as security key storage, e.g. for encrypting sensitive EEPROM or flash content on the device to prevent cloning (we are using a key derived from CPUID for EEPROM encryption now, but I'm thinking of moving to SRAM PUF as being harder to hack; on the other hand, it needs dedicated RAM region to perform reliably over years, as SRAM anti-aging strategies should be implemented to reduce PUF error rate).

[tcschmidt]

@olegart regarding PRNG seeding: we see shorter power-off intervals (< 1 s), but you're right that they are needed. For this reason, the current implementation already has a soft-boot state. After the (currently ongoing) rework of the 'random suite' in RIOT, we will keep the current random seed so that the random sequence will continue after a soft reset.

Regarding security key storage, this is also under way - @PeterKietzmann presented at the summit as @waehlisch pointed out above.

[tcschmidt]

@emmanuelsearch our current key problem with crypto is that we don't have crypto experts identified in the RIOT community (in Hamburg, we only have unofficial access in the background). You mention "set of well-known specialists" that you are "in close contact with": It would be really helpful to have a crypto expert team that performs mandatory reviews of any crypto contribution in RIOT (like the IETF does with security). Could you initiate? That would be really a huge step forward.

[olegart]

we see shorter power-off intervals (< 1 s)

Check it in cold environment (< -20 °C), some chips will preserve their RAM content for a few seconds. There are some "cold boot" attacks based on that fact.

we will keep the current random seed

If it's stored at a well known address, I can think of some attacks on it. Not exactly trivial, but doable. The only secure way to do it is to use dedicated backup registers with hardware tampering (STM32 has it, some other chips too).

I strongly believe that best strategy here is to implement proper CPU-specific PRNG seeding — and if not available on a given platform, issue compile-time warning about PRNG not properly seeded. Without HWRNG, the only adequate and widely available seed generation mechanism is an independent clocks jitter.

Regarding security key storage, this is also under way

Yes, I read it. Saw nothing on SRAM aging though — without anti-aging strategies, PUF key storage is unreliable, but implementing it means dedicated PUF region, a few Kbytes, so SRAM PUF may not be suitable for low-end systems.

[bergzand]

if there is an interesting experimental package PR which passes our basic quality tests, we merge it (recent examples: qdsa, libhydrogen, hacl).

Not necessarily a bad thing in my opinion.

What I think is that we should make a distinction here between algorithms that are considered experimental/stable and implementations that are considered experimental/safe. For example the AES algorithm can be considered stable, but the implementation in RIOT could be considered experimental.

I think a small bit of documentation on recommended crypto algorithms referencing the document linked by @emmanuelsearch could already help here. This could then be expanded to recommended implementations and possibly even gotchas to watch out for when using the implementations.

Maybe we can have a separate issue for problems with the RNG if it doesn't exist yet to keep the discussion here about cryptographic algorithms.

[tcschmidt]

we see shorter power-off intervals (< 1 s)

Check it in cold environment (< -20 °C), some chips will preserve their RAM content for a few seconds. There are some "cold boot" attacks based on that fact.

Yes, we know. There are also attacks that freeze memory. We are considering "normal" conditions and don't claim to be resistant to physical attacks. The objective is to make some decent mechanism available that is not particularly weak and always there.

The only secure way to do it is to use dedicated backup registers with hardware tampering (STM32 has it, some other chips too).

Thanks for this hint.

[smburdick]

Since the NIST has approved four new quantum resistant algorithms, is it worth reconsidering this issue at this stage?