Discussion :

[Patrick Ruiz]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
+// 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_blocksize		= SPECK64_BLOCK_SIZE,
+		.cra_ctxsize		= sizeof(struct speck64_tfm_ctx),
+		.cra_module		= THIS_MODULE,
+		.cra_u			= {
+			.cipher = {
+				.cia_min_keysize	= SPECK64_96_KEY_SIZE,
+				.cia_max_keysize	= SPECK64_128_KEY_SIZE,
+				.cia_setkey		= speck64_setkey,
+				.cia_encrypt		= speck64_encrypt,
+				.cia_decrypt		= speck64_decrypt
+			}
+		}
+	}
+};
+
+static int __init speck_module_init(void)
+{
+	return crypto_register_algs(speck_algs, ARRAY_SIZE(speck_algs));
+}
+
+static void __exit speck_module_exit(void)
+{
+	crypto_unregister_algs(speck_algs, ARRAY_SIZE(speck_algs));
+}
+
+module_init(speck_module_init);
+module_exit(speck_module_exit);
+
+MODULE_DESCRIPTION("Speck block cipher (generic)");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Eric Biggers <ebiggers@google.com>");
+MODULE_ALIAS_CRYPTO("speck128");
+MODULE_ALIAS_CRYPTO("speck128-generic");
+MODULE_ALIAS_CRYPTO("speck64");
+MODULE_ALIAS_CRYPTO("speck64-generic");
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index d5e23a1..058ed5e 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -3001,6 +3001,24 @@ static const struct alg_test_desc alg_test_descs[] = {
 			}
 		}
 	}, {
+		.alg = "ecb(speck128)",
+		.test = alg_test_skcipher,
+		.suite = {
+			.cipher = {
+				.enc = __VECS(speck128_enc_tv_template),
+				.dec = __VECS(speck128_dec_tv_template)
+			}
+		}
+	}, {
+		.alg = "ecb(speck64)",
+		.test = alg_test_skcipher,
+		.suite = {
+			.cipher = {
+				.enc = __VECS(speck64_enc_tv_template),
+				.dec = __VECS(speck64_dec_tv_template)
+			}
+		}
+	}, {
 		.alg = "ecb(tea)",
 		.test = alg_test_skcipher,
 		.suite = {
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 69fb51e..6b15a8a 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -14323,6 +14323,134 @@ static const struct cipher_testvec serpent_xts_dec_tv_template[] = {
 	},
 };

« Speck pourrait ne pas être aussi sécurisé qu’AES et ne doit être utilisé qu’avec les systèmes sur lesquels AES n’est pas assez rapide », prévient une fois de plus Biggers. Tomer Ashur a critiqué cette approche en arguant que l'on ne saurait offrir une telle solution aux utilisateurs en se disant « mieux vaut celui-là que rien », mais ne dit-on pas « un tien vaut mieux que deux tu l’auras ? »

Sources : commit Biggers, lkml, Tomer Ashur

Et vous ?

Quel commentaire faites-vous de l’approbation de ce commit ?

Avez-vous jeté un oeil au code source ? Si oui, la solution proposée vous satisfait-elle ? Expliquer

Quelles dispositions comptez-vous prendre lorsque viendra l'heure de faire usage de cette version du noyau Linux ?

Voir aussi :

WindsorGreen : les plans de la NSA pour casser les chiffrements auraient été découverts en libre accès sur Internet, par un chercheur en sécurité

Chiffrement : trop improbable la possibilité de l'existence de backdoors dans AES et autres ? Les travaux d'un chercheur tirent la sonnette d'alarme

Un algorithme de chiffrement inspiré de la fonction cardio-respiratoire sort, il serait incassable via une attaque par force brute

Le protocole HTTPS en danger ? L'algorithme RCA qu'il utilise pour le chiffrement cassé par des chercheurs pour SSL/TLS

Des chercheurs trouvent une faille dans l'algorithme RSA utilisé pour chiffrer les échanges en ligne

[Neckara]

Tomer Ashur a critiqué cette approche en arguant que l'on ne saurait offrir une telle solution aux utilisateurs en se disant « mieux vaut celui-là que rien »

Sophisme de la solution parfaite ?

[MikeRowSoft]

« 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 »

P.S. : c'est un système bipartie leur politique. Comme par hasard, politiquement, si il n'est pas avec eux il est contre eux, surtout sans en avoir fait la preuve que leur " truc " ne fonctionne pas selon les droits de la constitution des U.S.A. .

[Itachiaurion]

Sophisme de la solution parfaite ?

Attention a ne pas voir des sophismes partout, si le chiffrement est bidon autant passer sur AES256 ou twofish qui sont plus sécurisé. Effectivement on peut se dire qu'on est dans le cas du sophisme ce qui peut être potentiellement vrai, mais d'un point de vue sécurité il me parait dangereux de priorisé un chiffrement peu fiable mis en avant par la NSA quand on a des alternatives fonctionnel.

[Neckara]

Attention a ne pas voir des sophismes partout, si le chiffrement est bidon autant passer sur AES256 ou twofish qui sont plus sécurisé. […] (Effectivement on peut se dire qu'on est dans le cas du sophisme ce qui peut être potentiellement vrai, mais d'un point de vue sécurité il me parait dangereux de priorisé un chiffrement peu fiable mis en avant par la NSA quand on a des alternatives fonctionnel.

Justement de ce que je lis, ce n'est pas le cas, nous n'avons pas d'alternatives satisfaisantes pour certains type d'appareils:

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.