Controverse autour de Linux 4.17 : la dernière mouture du kernel supporte Speck

Un algorithme de chiffrement rejeté par l'ISO

Controverse autour de Linux 4.17 : la dernière mouture du kernel supporte Speck
Un algorithme de chiffrement rejeté par l’ISO

Lorsque Canonical a annoncé le lancement de la collecte des données sur les systèmes des utilisateurs d’Ubuntu au mois de février, la communauté a accouru pour voir de quoi il retourne effectivement. Même si l’entreprise a fait preuve de transparence en donnant le détail sur la nature des données collectées, la polémique sur les possibles usages n’avait pas manqué de faire surface. C’est un fait, dans la communauté on est très pointilleux et les dernières nouvelles liées à Linux 4.17 risquent de renforcer cette posture.

Linus Torvalds a annoncé la disponibilité de la dernière version du kernel il y a peu. Depuis les développements relatifs à la RC1, les axes importants en termes d’améliorations sont connus : réduction d’au moins 10 % de la consommation en mode idle de certains systèmes, arrivée de l’architecture Andes 32 utilisée par les appareils médicaux, portables, connectés et autres nécessitant une faible puissance, prise en charge par défaut des processeurs Cannonlake par le pilote DRM, etc. Grâce à un courriel paru sur la liste de diffusion Linux au mois d’avril 2018, il y a un détail supplémentaire à prendre en compte : un algorithme de chiffrement dénommé Speck fait partie des ajouts à la version 4.17 du noyau.


Très rapidement, ce qu’il faut noter à propos de cet algorithme de chiffrement, c’est qu’il vient d’être rejeté par l’Organisation internationale de normalisation (ISO). L’adoption de l’algorithme de chiffrement proposé par la NSA a connu deux reports entre 2014 et 2016, puis un troisième en 2017. D’après de précédents développements, le curriculum vitae plutôt « chargé » (en matière de surveillance électronique) de l’organisme gouvernemental du département de la Défense des États-Unis contribue à plomber ses efforts. Reuters a en effet rapporté avoir eu copie des échanges par courriels des experts en cryptographie qui ont pris part au processus d’approbation. D’après ces derniers, la NSA fait la promotion de Speck auprès d’ISO non parce qu’il s’agit d’outils de chiffrement de qualité, mais parce qu’elle sait comment les casser.

Un autre mail paru sur la lkml au début de ce mois vient éclairer la position des experts. Tomer Ashur – chercheur en cryptographie et membre de la commission ISO qui a statué sur le cas Speck – a livré certaines des raisons qui ont conduit au rejet de cet algorithme. « Je voudrais d’entrée de jeu rappeler que la NSA a fait un énorme boulot pour remplir les eaux de boue en argumentant que Simon & Speck sont sécurisés et que toutes les objections sont politiques. Ce n’est pas vrai et je m’en vais le démontrer à l’aide d’exemples. Le fait est que beaucoup de questions liées à la sécurité de ces algorithmes sont en suspens et la NSA a refusé d’y apporter des réponses à plusieurs reprises », a-t-il écrit. De façon brossée, le chercheur en sécurité a, par exemple, relevé que la documentation de la NSA n’est pas claire sur le choix du nombre de tours. En sus, il y a que même avec le nombre de tours indiqué par l’Agence, les marges de sécurité réévaluées sont plus faibles que celles avancées par cette dernière. Enfin, il y a pire : Tomer Ashur est connu comme celui qui a cassé Speck ; le chercheur dit avoir publié une preuve de concept.

Que fait donc un algorithme aussi controversé au sein du kernel Linux ?

L’intervention de Tomer Ashur au sein de la lkml fait suite à celle d’Eric Biggers de Google, l'auteur du commit controversé au sein du kernel Linux. Biggers est pour sa part d’avis qu’au-delà de la polémique sur les origines de Speck, il s’agit de l’algorithme de chiffrement le plus abouti dans la catégorie des versions légères destinées à tourner sur des appareils sevrés d’instructions de prise en charge du chiffrement AES (les dispositifs mobiles bas de gamme équipés de processeurs ARMv7, etc.). « Actuellement, ces dispositifs ne bénéficient pas de chiffrement parce qu’AES n’est pas assez rapide, ce, même dans le cas de la mise en œuvre de la version pour processeur dotés du support de NEON », a-t-il écrit.

En février 2018, Biggers a proposé une implémentation générique de l’algorithme de chiffrement Speck en version légère sur 5 variantes (pour un total de dix dans la famille). Il s’agissait d’un correctif de la proposition originale (faite en décembre 2017) qui portait sur l’algorithme de chiffrement ChaCha20. Le commit a été approuvé par Herbert Xu, un des mainteneurs du sous-système de chiffrement de Linux.

[CODE]+// SPDX-License-Identifier: GPL-2.0

+#include <asm/unaligned.h>
+#include <linux/bitops.h>
+#include <linux/crypto.h>
+#include <linux/init.h>
+#include <linux/module.h>
+
+/* Speck128 */
+
+#define SPECK128_BLOCK_SIZE 16
+
+#define SPECK128_128_KEY_SIZE 16
+#define SPECK128_128_NROUNDS 32
+
+#define SPECK128_192_KEY_SIZE 24
+#define SPECK128_192_NROUNDS 33
+
+#define SPECK128_256_KEY_SIZE 32
+#define SPECK128_256_NROUNDS 34
+
+struct speck128_tfm_ctx {
+ u64 round_keys[SPECK128_256_NROUNDS];
+ int nrounds;
+};
+
+static __always_inline void speck128_round(u64 *x, u64 *y, u64 k)
+{
+ *x = ror64(*x, 8);
+ *x += *y;
+ *x ^= k;
+ *y = rol64(*y, 3);
+ *y ^= *x;
+}
+
+static __always_inline void speck128_unround(u64 *x, u64 *y, u64 k)
+{
+ *y ^= *x;
+ *y = ror64(*y, 3);
+ *x ^= k;
+ *x -= *y;
+ *x = rol64(*x, 8);
+}
+
+static void speck128_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+ const struct speck128_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ u64 y = get_unaligned_le64(in);
+ u64 x = get_unaligned_le64(in + 8);
+ int i;
+
+ for (i = 0; i < ctx->nrounds; i++)
+ speck128_round(&x, &y, ctx->round_keys[i]);
+
+ put_unaligned_le64(y, out);
+ put_unaligned_le64(x, out + 8);
+}
+
+static void speck128_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+ const struct speck128_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ u64 y = get_unaligned_le64(in);
+ u64 x = get_unaligned_le64(in + 8);
+ int i;
+
+ for (i = ctx->nrounds - 1; i >= 0; i--)
+ speck128_unround(&x, &y, ctx->round_keys[i]);
+
+ put_unaligned_le64(y, out);
+ put_unaligned_le64(x, out + 8);
+}
+
+static int speck128_setkey(struct crypto_tfm *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct speck128_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ u64 l[3];
+ u64 k;
+ int i;
+
+ switch (keylen) {
+ case SPECK128_128_KEY_SIZE:
+ k = get_unaligned_le64(key);
+ l[0] = get_unaligned_le64(key + 8);
+ ctx->nrounds = SPECK128_128_NROUNDS;
+ for (i = 0; i < ctx->nrounds; i++) {
+ ctx->round_keys[i] = k;
+ speck128_round(&l[0], &k, i);
+ }
+ break;
+ case SPECK128_192_KEY_SIZE:
+ k = get_unaligned_le64(key);
+ l[0] = get_unaligned_le64(key + 8);
+ l[1] = get_unaligned_le64(key + 16);
+ ctx->nrounds = SPECK128_192_NROUNDS;
+ for (i = 0; i < ctx->nrounds; i++) {
+ ctx->round_keys[i] = k;
+ speck128_round(&l[i % 2], &k, i);
+ }
+ break;
+ case SPECK128_256_KEY_SIZE:
+ k = get_unaligned_le64(key);
+ l[0] = get_unaligned_le64(key + 8);
+ l[1] = get_unaligned_le64(key + 16);
+ l[2] = get_unaligned_le64(key + 24);
+ ctx->nrounds = SPECK128_256_NROUNDS;
+ for (i = 0; i < ctx->nrounds; i++) {
+ ctx->round_keys[i] = k;
+ speck128_round(&l[i % 3], &k, i);
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/* Speck64 */
+
+#define SPECK64_BLOCK_SIZE 8
+
+#define SPECK64_96_KEY_SIZE 12
+#define SPECK64_96_NROUNDS 26
+
+#define SPECK64_128_KEY_SIZE 16
+#define SPECK64_128_NROUNDS 27
+
+struct speck64_tfm_ctx {
+ u32 round_keys[SPECK64_128_NROUNDS];
+ int nrounds;
+};
+
+static __always_inline void speck64_round(u32 *x, u32 *y, u32 k)
+{
+ *x = ror32(*x, 8);
+ *x += *y;
+ *x ^= k;
+ *y = rol32(*y, 3);
+ *y ^= *x;
+}
+
+static __always_inline void speck64_unround(u32 *x, u32 *y, u32 k)
+{
+ *y ^= *x;
+ *y = ror32(*y, 3);
+ *x ^= k;
+ *x -= *y;
+ *x = rol32(*x, 8);
+}
+
+static void speck64_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+ const struct speck64_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ u32 y = get_unaligned_le32(in);
+ u32 x = get_unaligned_le32(in + 4);
+ int i;
+
+ for (i = 0; i < ctx->nrounds; i++)
+ speck64_round(&x, &y, ctx->round_keys[i]);
+
+ put_unaligned_le32(y, out);
+ put_unaligned_le32(x, out + 4);
+}
+
+static void speck64_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+ const struct speck64_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ u32 y = get_unaligned_le32(in);
+ u32 x = get_unaligned_le32(in + 4);
+ int i;
+
+ for (i = ctx->nrounds - 1; i >= 0; i--)
+ speck64_unround(&x, &y, ctx->round_keys[i]);
+
+ put_unaligned_le32(y, out);
+ put_unaligned_le32(x, out + 4);
+}
+
+static int speck64_setkey(struct crypto_tfm *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct speck64_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ u32 l[3];
+ u32 k;
+ int i;
+
+ switch (keylen) {
+ case SPECK64_96_KEY_SIZE:
+ k = get_unaligned_le32(key);
+ l[0] = get_unaligned_le32(key + 4);
+ l[1] = get_unaligned_le32(key + 8);
+ ctx->nrounds = SPECK64_96_NROUNDS;
+ for (i = 0; i < ctx->nrounds; i++) {
+ ctx->round_keys[i] = k;
+ speck64_round(&l[i % 2], &k, i);
+ }
+ break;
+ case SPECK64_128_KEY_SIZE:
+ k = get_unaligned_le32(key);
+ l[0] = get_unaligned_le32(key + 4);
+ l[1] = get_unaligned_le32(key + 8);
+ l[2] = get_unaligned_le32(key + 12);
+ ctx->nrounds = SPECK64_128_NROUNDS;
+ for (i = 0; i < ctx->nrounds; i++) {
+ ctx->round_keys[i] = k;
+ speck64_round(&l[i % 3], &k, i);
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/* Algorithm definitions */
+
+static struct crypto_alg speck_algs[] = {
+ {
+ .cra_name = "speck128",
+ .cra_driver_name = "speck128-generic",
+ .cra_priority = 100,
+ .cra_flags = CRYPTO_ALG_TYPE_CIPHER,
+ .cra_blocksize = SPECK128_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct speck128_tfm_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_u = {
+ .cipher = {
+ .cia_min_keysize = SPECK128_128_KEY_SIZE,
+ .cia_max_keysize = SPECK128_256_KEY_SIZE,
+ .cia_setkey = speck128_setkey,
+ .cia_encrypt = speck128_encrypt,
+ .cia_decrypt = speck128_decrypt
+ }
+ }
+ }, {
+ .cra_name = "speck64",
+ .cra_driver_name = "speck64-generic",
+ .cra_priority = 100,
+ .cra_flags = CRYPTO_ALG_TYPE_CIPHER,
+ .cra[/]...