Sécuriser ses échanges en NFC
Nous avons vu dans les précédent articles ce qu’était le NFC et la norme principale ISO/IEC 14443. Je fais une petite pause dans les normes pour aborder un sujet majeur de la communication NFC, la sécurité !!
Trop souvent, l’usage d’étiquettes NFC ou la lecture de l’ID de la carte fait oublier ce sujet. On tombe après sur des articles « choc » : « Le NFC est moins sécurisé que …. » ou alors « Une faille critique découverte sur les objets connectés en NFC …« , et c’est encore ce qui m’est arrivé ce weekend. Mais évidemment, si personne ne chiffre ses communications on ne peut pas s’attendre à des miracles…
La norme ISO/IEC 7816-4 décrit un mode d’authentification basé sur les clefs symétriques (« Three Pass Authentication »). Ce processus assez simple à mettre en oeuvre peut servir à chiffrer les informations échangées durant la session.
« Three Pass Authentication », la fameuse « passe triple divergente » ?
On parle de « Three Pass » parce que l’authentification est réalisée avec trois échanges d’informations. Cette technique permet de vérifier que tout le monde a la même clef sans jamais se l’échanger.
En résumé : « Je sais que tu sais que je sais que tu as la même clef que moi ».
Le concept est assez simple puisqu’il s’agit d’échanger un message chiffré entre le PCD et la PICC. On s’assure qu’en connaissant le message d’origine et en déchiffrant le message reçu avec la clef on retrouve bien le message d’origine.
J’ai publié un projet sur GitHub pour illustrer ce fonctionnement (il y a aussi un chiffrement RSA mais ce n’est pas ce qui nous intéresse dans cet article). Vous pouvez presque l’utiliser tel quel. Il s’agit simplement d’un client et d’un serveur TCP qui communiquent après s’être authentifié avec la méthode expliquée dans cet article. A noter que le PCD est le client et la PICC le serveur.
Etapes
Voici la liste des étapes lors de l’authentification.
| Etape | Description | Echanges | ||
|
1 |
Le PCD demande à la PICC de générer un « challenge ». La PICC génère une suite d’octets aléatoire et la retourne au PCD. |
|
||
|
2 |
Le PCD, lorsqu’il reçoit ce « challenge » génère à son tour une suite d’octet aléatoire, il concatène ces deux suites et chiffre l’ensemble avec la clef et l’algorithme qu’il souhaite utiliser. La chaîne obtenue, l’index et l’algorithme de la clef à utiliser sont envoyés à la PICC. La PICC, à la réception de ces informations déchiffre avec sa propre clef, et compare le résultat avec la valeur générée en étape 1. Si cela correspond on est donc certain que le PCD à la même clef que la PICC. |
|
||
|
3 |
Le PCD génère un challenge et l’envoi à la PICC accompagné de l’index et de l’algorithme de la clef qu’il souhaite utiliser. La PICC génère à son tour une suite d’octet aléatoire, elle concatène ces deux suites et chiffre l’ensemble avec la clef et l’algorithme demandés. La chaîne obtenue est retournée au PCD. |
|
||
|
4 |
Le PCD, à la réception de ces informations, déchiffre avec sa propre clef et compare le résultat avec la valeur générée en étape 3. Si cela correspond on est donc certain que la PICC à la même clef que le PCD. |
|||
|
5 |
La clef de session est construite avec les challenges générés par le PCD (étape 2) et la PICC (étape 3). C’est cette clef de session qui est utilisée pour chiffrer et déchiffrer les informations échangées par la suite. |
Exemples
Maintenant que l’on connait les étapes, voici une transcription des échanges.
La clef a utiliser possède l’index « 1 » et vaut « 00 01 02 03 04 05 06 07 08 09 AA BB CC DD EE FF ».
L’algorithme est « AES-128 ».
Echange pour une authentification réussie
Le PCD et la PICC ont bien la même clef.
|
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 |
| PCD side >> challenge() | PICC side | cPICC1: 89 DA 74 5C 21 9E 4C 18 68 32 85 F8 76 1C 59 63 << 89 DA 74 5C 21 9E 4C 18 68 32 85 F8 76 1C 59 63 | PCD side | cPCD1: C4 56 F7 72 12 F3 20 10 9B FF 89 97 6B 7A 2C 26 | encode: ek(cPCD1+cPICC1): F2 23 09 1C 41 8F 4B DC D3 50 2E B5 73 42 69 BE 48 13 FF 3F 8C 48 7A 5F 64 65 AD 33 DC B1 FA 5F | PCD key with index: 1 : 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF | algorithm: AES >> algorithm: AES kIndex: 1 ek(cPCD1+cPICC1): F2 23 09 1C 41 8F 4B DC D3 50 2E B5 73 42 69 BE 48 13 FF 3F 8C 48 7A 5F 64 65 AD 33 DC B1 FA 5F | PICC side | decode: ek(cPCD1+cPICC1): F2 23 09 1C 41 8F 4B DC D3 50 2E B5 73 42 69 BE 48 13 FF 3F 8C 48 7A 5F 64 65 AD 33 DC B1 FA 5F | PICC key with index: 1 : 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF | algorithm: AES | cPCD1': C4 56 F7 72 12 F3 20 10 9B FF 89 97 6B 7A 2C 26 | cPICC1': 89 DA 74 5C 21 9E 4C 18 68 32 85 F8 76 1C 59 63 << OK (cPICC1 == cPICC1') | PCD side | cPCD2: 05 59 76 C1 BA 84 6A DE 54 86 F7 4E F6 F5 9C 2A >> algorithm: AES kIndex: 1 cPCD2: 05 59 76 C1 BA 84 6A DE 54 86 F7 4E F6 F5 9C 2A | PICC side | cPICC2: F9 E9 CA 4B 4C EE AE 69 ED 80 48 0A 30 C2 F0 A8 | encode: ek(cPCD1+cPICC1): C4 69 4B 24 E5 D3 30 BD 52 6A 73 83 0B E0 FC 66 06 58 E7 DE C8 8A AA 8C 2C 85 CF C3 84 53 17 D3 | PICC key with index: 1 : 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF | algorithm: AES << ek(cPICC2+cPCD2): C4 69 4B 24 E5 D3 30 BD 52 6A 73 83 0B E0 FC 66 06 58 E7 DE C8 8A AA 8C 2C 85 CF C3 84 53 17 D3 | PCD side | decode: ek(cPICC2+cPCD2): C4 69 4B 24 E5 D3 30 BD 52 6A 73 83 0B E0 FC 66 06 58 E7 DE C8 8A AA 8C 2C 85 CF C3 84 53 17 D3 | PCD key with index: 1 : 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF | algorithm: AES | cPCD2': 05 59 76 C1 BA 84 6A DE 54 86 F7 4E F6 F5 9C 2A | cPICC2': F9 E9 CA 4B 4C EE AE 69 ED 80 48 0A 30 C2 F0 A8 | cPCD2 == cPCD2' [OK] |
Échange pour une authentification refusée (coté PICC)
Le PCD n’utilise pas la bonne clef ou ne la connaît pas.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
| PCD side >> challenge() | PICC side | cPICC1: 38 43 B2 EC C3 90 BF 83 6C EF 35 30 49 92 E7 7C << 38 43 B2 EC C3 90 BF 83 6C EF 35 30 49 92 E7 7C | PCD side | cPCD1: 6C BB FD 68 F1 D9 F5 00 C5 55 29 E2 04 F5 C3 11 | encode: ek(cPCD1+cPICC1): 24 1F 9B 69 76 58 A7 6A 9F C1 A9 FE 6A 4D 65 AC F9 35 C0 42 E9 2B D9 52 A6 9D BC CD E1 61 15 CF | PCD key with index: 1 : AA BB CC DD EE FF 00 11 22 33 44 55 66 77 88 99 | algorithm: AES >> algorithm: AES kIndex: 1 ek(cPCD1+cPICC1): 24 1F 9B 69 76 58 A7 6A 9F C1 A9 FE 6A 4D 65 AC F9 35 C0 42 E9 2B D9 52 A6 9D BC CD E1 61 15 CF | PICC side | decode: ek(cPCD1+cPICC1): 24 1F 9B 69 76 58 A7 6A 9F C1 A9 FE 6A 4D 65 AC F9 35 C0 42 E9 2B D9 52 A6 9D BC CD E1 61 15 CF | PICC key with index: 1 : 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF | algorithm: AES | cPCD1': D5 3B 71 36 8C 6F BE 95 F3 69 4C 53 0F B2 16 10 | cPICC1': 7E 93 CC 07 EC C6 FD 0E BC A6 AE F4 D5 EB E8 73 << FAILED (cPICC1 != cPICC1') |
Echange pour une authentification refusée (coté PCD)
Dans ce cas de figure la PICC ne connaît pas la clef, elle simule le succès de la première passe.
|
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 |
| PCD side >> challenge() | PICC side | cPICC1: 2D 9A 41 04 A3 57 3B FF 98 1F 0D 04 FB 95 7B 04 << 2D 9A 41 04 A3 57 3B FF 98 1F 0D 04 FB 95 7B 04 | PCD side | cPCD1: 85 93 32 12 9C 4B 79 F4 1E E0 EB B5 34 B8 4E EF | encode: ek(cPCD1+cPICC1): F0 0A 64 EA 05 44 AF E1 28 BB 21 23 85 BB DF 7B 5C 06 C6 EE 03 E4 E0 E6 11 BC 14 3F 89 82 CB 58 | PCD key with index: 1 : 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF | algorithm: AES >> algorithm: AES kIndex: 1 ek(cPCD1+cPICC1): F0 0A 64 EA 05 44 AF E1 28 BB 21 23 85 BB DF 7B 5C 06 C6 EE 03 E4 E0 E6 11 BC 14 3F 89 82 CB 58 | PICC side | Always success << OK (fake) | PCD side | cPCD2: BB 0F 11 E7 E5 79 A9 B0 74 C4 0C 94 97 E5 60 00 >> algorithm: AES kIndex: 1 cPCD2: BB 0F 11 E7 E5 79 A9 B0 74 C4 0C 94 97 E5 60 00 | PICC side | cPICC2: B6 E8 88 A6 B8 8A 9F 05 3B CB 44 48 B5 C8 FB 34 | encode: ek(cPCD1+cPICC1): FB DF 04 CC 61 86 BB 1D 38 06 1F BB 68 AC 2C 30 E3 E0 98 98 AC 0C EE 81 23 9A 59 E6 6B 68 2A DC | PICC key with index: 1 : AA BB CC DD EE FF 00 11 22 33 44 55 66 77 88 99 | algorithm: AES << ek(cPICC2+cPCD2): FB DF 04 CC 61 86 BB 1D 38 06 1F BB 68 AC 2C 30 E3 E0 98 98 AC 0C EE 81 23 9A 59 E6 6B 68 2A DC | PCD side | decode: ek(cPICC2+cPCD2): FB DF 04 CC 61 86 BB 1D 38 06 1F BB 68 AC 2C 30 E3 E0 98 98 AC 0C EE 81 23 9A 59 E6 6B 68 2A DC | PCD key with index: 1 : 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF | algorithm: AES | cPCD2': 11 13 E6 4F 2F CB 7F F2 F6 D4 5A 8C 4C B8 49 24 | cPICC2': 95 FC 9E CF FA 50 98 86 E6 17 90 DB 8B 88 E1 90 [FAILED] (cPCD2 != cPCD2') |
Le reste des échanges
Une fois le client et le serveur authentifiés, les échanges sont chiffrés avec la clef de session qui est générée. A noter un point crucial, on ne réinitialise pas le processus de chiffrement à chaque fois. En effet, le vecteur d’initialisation doit être conservé d’un chiffrage à l’autre (contrairement à la phase d’authentification). La norme décrit les événements qui doivent remettre à zéro le vecteur d’initialisation.
Conclusion
Ce mode d’authentification est relativement simple à mettre en oeuvre et offre déjà un bon niveau de sécurité dans vos échanges. Lorsque l’on déploie des services P2P sur Smartphone la mise en place de ce système permet de garantir que les échanges ne circulent pas en clair et que les deux communicants se « connaissent ». Il est tout à fait possible de l’implémenter dans une communication avec un objet connecté, en NFC ou autre. Veillez seulement à bien protéger vos clefs symétriques…
Mais au final, peu importe le comment, si les données échangées sont privées, sensibles, critiques ou que vous ne souhaitez simplement pas que n’importe qui puisse les lire, chiffrer les, même avec le plus basique des algorithmes.
They’re very convincing and can certainly work. Nonetheless, the posts are very short for newbies.
It was definitely informative. Your website is useful. Many thanks for sharing!
Could you please extend them a little from next time? Thank you for the post.