Xpost/fup
Bonjour à tous,
Je m'arrache les cheveux sur un problème de signature ECC entre un
microcontrôleur AVR (ATmega1284P) et un serveur Unix (NetBSD ou
Linux, même combat, tournant avec un CPU i7).
Je cross-post vers fr.comp.lang.c car j'ai déjà eu des trucs
bizarres avec avr-gcc. Durant une époque, la bibliothèque micro-ecc
renvoyaient des erreurs lorsqu'elle était compilée avec des gcc
récents. J'ai néanmoins réinstallé avr-gcc 5.5 (je suis sûr que
micro-ecc fonctionnait avec cette version), j'ai toujours le même
genre de dysfonctionnement.
La bibliothèque en question est la suivante:
https://github.com/kmackay/micro-ecc J'envoie des trames de données sur un réseau 4G/LTE. L'émetteur
est le CPU AVR, le destinataire, le serveur Unix. Ces trames ont la
forme suivante :
identifiant (4 octets)
séquence (8 octets)
signature ECC (64 octets)
La signature ECC est calculée comme suit :
- sha512 des 12 octets (identifiant/séquence), soit 64 octets ;
- signature ECC (courbe secp256r1).
Côté serveur, le soft j'ai écrit une interface C à la micro-ecc.
Je peux créer un couple de clefs, signer un message et tester cette
signature :
RPL/2> "secp256r1" ecc$makeKey
2: [ 150 222 38 181 64 231 35 242 195 182 34 226 218 7 10 2 125 229 110
111 171 17 123 189 197 230 99 100 93 209 18 235 ]
1: [ 238 188 81 80 245 4 235 216 250 199 84 172 89 221 27 223 225 197
106 121 196 7 24 65 188 210 222 236 210 192 160 204 188 30 238 15 22 144
194 255 51 74 38 123 189 127 25 252 184 40 158 78 177 38 217 20 204 105
83 71 96 198 162 99 ]
RPL/2> 'PUBLIC' save 'PRIVATE' SAVE
=> Création des clefs publique et privée.
1: [ 145 48 151 115 172 53 68 106 17 115 57 243 117 43 143 51 53 135 188
46 116 205 130 225 100 137 149 154 91 82 203 22 221 150 143 241 195 74
73 26 158 253 186 37 59 79 251 94 177 150 202 241 128 191 16 209 34 78
53 64 125 36 5 40 ]
RPL/2> 'HASH' save
=> Génération d'un message aléatoire (64 octets).
RPL/2> HASH PRIVEE "secp256r1" ecc$sign
1: [ 170 24 63 204 115 102 157 233 6 115 117 108 11 100 19 153 210 177
250 25 227 33 26 213 138 133 243 251 109 228 9 16 19 189 173 20 0 10 127
127 212 44 112 105 81 89 152 67 97 181 93 235 86 178 226 100 60 99 89 198
224 16 53 151 ]
RPL/2> 'SIGNATURE' save
RPL/2> HASH SIGNATURE PUBLIC "secp256r1" ecc$verify
1: 1
J'obtiens un 1, donc la signature est valide. Si je change un bit de
la signature, le résultat est 0.
Donc, sur un serveur, je suis capable de créer deux clefs, de signer
un message aléatoire et de vérifier l'authenticité de la signature.
Maintenant, je mets la clef privée dans l'eeprom d'un ATMega1284P.
Je génère mes 12 octets (identifiant sur 4 octets + numéro de
séquence sur 8), je calcule une somme de hash (SHA512) que je
concatène aux 12 premiers octets. J'obtiens donc 76 octets (12 +
64). J'envoie le tout vers le serveur.
La console série de l'AVR m'indique par exemple qu'elle envoie :
[ 0 0 0 1 0 0 0 0 0 0 0 9 127 20 252 122 35 48 159 126 140 159 131 86 74
213 30 206 84 59 193 200 124 132 36 138 201 175 222 138 171 145 144 90 41
30 229 56 191 143 33 173 217 246 190 229 97 231 112 142 165 37 156 135 98
57 65 185 190 55 133 227 94 101 142 93 ]
Le serveur récupère exactement les mêmes données (j'ai vérifié à
plusieurs reprises). Il extrait alors les douze premiers octets et
calcule localement la somme de hash.
Le serveur m'affiche :
[ 144 142 178 161 137 226 153 13 253 24 25 136 216 147 230 166 115 203 144
127 64 222 236 238 95 127 176 128 224 28 194 33 162 164 181 168 56 135 255
134 51 100 136 254 240 220 167 22 188 159 8 43 63 28 220 42 26 77 26 9 220
37 119 255 ]
Cette somme de contrôle est identique à celle qui est calculée sur
l'AVR (j'ai vérifié).
Il n'y a donc aucune raison que la vérification de la signature
échoue côté serveur puisque j'ai la somme de contrôle identique à
celle générée côté AVR, la signature et la clef publique.
OR ELLE ÉCHOUE systématiquement ! La fonction uECC_verify() demande
la somme de contrôle, la signature, la clef publique et la courbe.
Tous les paramètres sont bons, et ça échoue.
La différence entre les deux configurations est le processeur sur
lequel la signature est générée et je ne sais plus où chercher.
Je suis preneur de toute idée.
Bien cordialement,
JB
-- Si votre demande me parvient en code 29, je vous titiouillerai volontiersune réponse.
micro-ecc et communication AVR/Unix