Catégorie : Blog

Blog

Mifare Desfire EV3 : Quoi de neuf ?

Juin 8, 2020 par Julien Micoud

NXP à annoncé le 2 juin la sortie de ses puces Desfire EV3 destinées aux smart-city. Nous allons voir en détails les caractéristiques de cette nouvelle puce et la comparer aux version précédentes : Desfire EV2 et Desfire EV1. Cet article est préliminaire, l’annonce étant récente, l’ensemble des informations de cet article proviennent des documents NXP et ne tiennent pas compte des futures implémentations de la puce par les constructeurs de badge et fabricants de contrôle d’accès.

Les nouveautés annoncées de la puces Desfire EV3

NXP annonce les nouveautés suivantes :

Perfomances améliorées

  • Plus grande durée de rétention des données (25 ans contre 10 ans précédemment)
  • Plage de fonctionnement améliorée et des vitesses de transaction plus élevées par rapport à ses prédécesseurs (1,5 fois plus rapide que les desfire EV1)

Sécurité améliorée

  • Ajout d’un Timer de transaction permettant d’eviter les attaques de type « man-i-the-middle »
  • Nouvelle fonctionnalité de messagerie Secure Unique NFC (SUN), offre un moyen plus sûr de maintenir la confidentialité et l’intégrité des données (pour les mobiles).

Prise en charge mobile et multi-applications

  • Déploiement possible sur mobile NFC via le service cloud mifare 2GO
  • clés préchargées pour la gestion déléguée des applications permettent d’ajouter de nouveaux services à la carte déjà déployée

Caractéristiques et comparatif des puces Desfire

Le tableau comparatif ci-dessous synthétise les éléments techniques des puces Mifare Desfire EV1, Desfire EV2, Defire EV3

CaractéristiquesMifare Desfire EV1Mifare Desfire EV2Mifare Desfire EV3
Mémoire de données EEPROM2/4/8KB2/4/8/16/32KB2/4/8KB
Taille UID7 octets7 octets7 octets
Certification critères communsEAL 4+EAL 5+EAL 5+
Algorithmes cryptographiquesDES, 3DES, AES128DES, 3DES, AES128DES, 3DES, AES128
Protection des communicationsD40 Natif1, EV1D40 Natif1, EV11, EV2D40 Natif1, EV11, EV2
Nombre d’applications28Illimité2Illimité2
Nombre de fichiers par application323232
Max de fichier avec sauvegardes323232
Commandes ISO/IEC7816-4888
ID aléatoireouiouioui
ATS configurableOui, octets historiques seulementOui, tous paramètres (FSCI supporte jusqu’à 256 octets)Oui, tous paramètres (FSCI supporte jusqu’à 256 octets)
Buffer de communication64 octetsjusqu'à 128 octetsjusqu'à 256 octets
Chaining durant le transfert de données Natif (AFh)Natif (AFh) ou ISO/IEC14443-4Natif (AFh) ou ISO/IEC14443-4
Multiple jeu de clés tournantesnonouioui
MIsmartApp (Gestion déléguée des applications)nonouioui
Support de la fonction NXP AppXplorernonoui, autoconfigurationoui, Clefs DAM3 préchargées en usine
Gestion des applications partagéesnonouioui
Plusieurs clés par droit d'accèsnonouioui
Commande d’actualisation d’enregistrementnonouioui
Transaction MACnonouioui
Timer de transactionnonnonoui
Messagerie dynamique sécuriséenonnonoui
Architecture de badge virtuelnonouioui
Contrôle de proximité du badgenonouioui
Contrôle de puce originalenonouioui
SUN (Secure Unique NFC Message)nonnonoui, compatible avec NTAG DNA
Durée de rétentions des données10 ans10 ans25 ans
Nombre de cycles d'écriture500 000500 0001 000 000
Distance de lecturejusqu'à 10cmjusqu'à 10cmjusqu'à 10cm
gestion des accéspar fichier (clef de lecture et/ou d'ecriture)par fichier (clef de lecture et/ou d'ecriture)jusqu'à 8 clefs par droit d’accès

1 : Permet la rétrocompatibilité

2 : Autant que la taille de la mémoire le permet

3 : Delegated Application Management (Multi-Application) Gestion des applications déléguées (MIsmartApp) pour donner des droits à la création et à la gestion d’applications tierces.

Révolution ou évolution ?

La lecture des éléments technique ci-dessus me font penser que cette nouvelle évolution de la puce Desfire est essentiellement tournée vers les application mobiles et NFC et le service Cloud associé. Les gains en performance et en sécurité sont somme toute assez léger.

Toutefois, la fonctionnalité de clefs préchargées conçue afin de faciliter le déploiement de nouvelles applications sur un parc de badges existant semble intéressante. Cette fonctionnalité pourrait être mise à profit dans le cadre de badges unique multiservices notamment. Il reste à voir maintenant comment les solutions logiciels vont tirer parti de cela.

Enfin, plus largement on note une accélération autour des technologies sans contact avec de nouvelles évolutions de plus en plus rapprochées. Demain nous aurons certainement des entreprises ou administration avec des parcs de badges EV1, EV2 et EV3 en circulation. Heureusement toutes ces évolutions sont rétrocompatible mais au détriment des nouvelles fonctionnalités. Serions-nous entrain de rentrer dans la même course aux nouveautés que celle qui anime le monde des logiciels ou des cameras ?

 

Pour aller plus loin sur la sécurité des technologies de badges

Au delà de la sécurité intrinsèque du produit je vous invite à lire cet article : « La certification CSPN des produits de contrôle d’accès est-ce suffisant ? » pour comprendre pourquoi il est important de prendre en compte l’ensemble des élément constituant un système de sécurité. Pour vous accompagner dans cette démarche,  ASFA Conseil vous propose des prestations d’audit de sécurité du SI de sûreté et d’accompagnement à la Conception d’architectures sûreté.

Cet article est une synthèse des documents suivant, je vous invite à les consulter pour aller plus loin :

Blog

Bureau d’étude Sûreté, Expert Sûreté ou Architecte ?

Mai 4, 2020 par Julien Micoud

L’origine du métier d’architecte

Dans « architecte en systèmes d’informations de sûreté » je retiens tout d’abord la notion d’architecte. C’est une notion qui nous vient du monde du bâtiment, son rôle est de concevoir les bâtiments et de réaliser le suivi de sa construction. L’architecte veille au bon respect des règles de l’art et des normes.

Cette notion s’est donc tout naturellement étendue aux systèmes d’informations classiques « bureautique » voire Cloud mais curieusement cette notion est peu présente dans le monde de la sûreté.

Cependant, entre la multiplication des contraintes réglementaires et recommandations (RGPD, LPM, ANSSI, APSAD, …) et la prédominance de l’informatique dans notre métier il est plus que nécessaire de pouvoir faire appel à un professionnel reconnu dans le domaine.

Qu’apporte l’architecte en systèmes d’informations de sûreté à son client ?

L’objectif premier de l’architecte en systèmes d’informations de sûreté est de garantir à son client que le système défini et installé sera conforme aux règles de l’art, à la réglementation et aux bonnes pratiques de cybersécurité. Il pourra, fort de ses connaissances, l’optimiser, le rendre plus efficace, plus pertinent. Enfin la sécurité devra être prise en compte dès la conception pour éviter d’accumuler des couches de sécurité pour rattraper des éventuelles vulnérabilités.

Qui peut jouer ce rôle ?

Jusqu’alors les ingénieurs avant-ventes des distributeurs ou constructeurs – dont j’ai fait partie – jouaient plus ou moins ce rôle grâce à leur « devoir de conseil ». Néanmoins la partialité, ou tout simplement le manque de maitrise de l’ensemble du scope par ces profils ne permettent pas d’apporter une réponse complète à cette problématique.

Les bureaux d’étude ? Les experts sûreté ? Oui ou non selon la spécialité de chacun !

Finalement, le terme est beaucoup trop flou, entre ceux qui sont parfaits pour réaliser les plans courant fort, courant faible d’un bâtiment public, ceux qui sont spécialisés sur une technologie ou sur un logiciel, les anciens des forces spéciales et finalement ceux qui additionnent les propositions des fabricants. Attention l’idée n’est pas d’émettre un jugement à l’encontre de ces professionnels mais plutôt de démontrer que le terme est trop imprécis. C’est pourquoi le terme architecte en SI de sureté me semble plus adapté à la mission que j’ai décrite précédemment.

Quelles compétences ?

L’architecte étant un homme-orchestre il se doit d’être en mesure de dialoguer avec un ensemble de spécialistes et de synthétiser les expertises au profit de son client. Ainsi les compétences suivantes me semblent indispensables :

Les compétences humaines dans un premier temps : comprendre le besoin et savoir le retranscrire. Savoir prendre du recul et être méthodique.

Les compétences techniques pointues ensuite, connaissances des technologies, des logiciel et systèmes largement diffusés. Mais également des connaissances informatiques : infrastructure, OS, virtualisation et bien évidemment en cybersécurité.

Enfin des connaissances réglementaires, différentes en fonction du client et du projet : RGS, LPM, IGI1300, PCI DSS, APSAD R81, R82, D83, D32, Recommandations ANSSI « Recommandations sur la sécurisation des systèmes de contrôle d’accès physique et de vidéoprotection », guide de bonne pratique, etc

Mais ce triptyque ne serait pas complet sans la veille technologique que l’architecte doit mettre en place constamment pour se remettre en cause et sans cesse évoluer dans sa pratique.

Blog

La certification CSPN des produits de contrôle d’accès est-ce suffisant ?

Mai 4, 2019 , par Julien Micoud

De nos jours de plus en plus de solutions de contrôle d’accès physique font état de leur certification CSPN établie par l’ANSSI. Ces certifications sont une bonne chose en soi car elles démontrent la capacité et la volonté d’un éditeur à produire des solutions robustes aux attaques informatiques.

Toutefois comme le rappelle l’ANSSI sur sa page consacrée aux produits certifiés CSPN

« […], la certification ne garantit pas que le produit certifié soit totalement exempt de vulnérabilités exploitables. »

Et c’est là que le bât blesse. En effet, le process de certification garantit qu’à une date donnée, avec une version donnée, il n’a pas été possible dans un temps forcément contraint de trouver une vulnérabilité. En aucun cas la certification ne garantit que le produit est ou sera invulnérable. De plus toute modification du produit (même une mise à jour mineure de version) fait perdre la certification. A titre d’exemple, nous pouvons citer le produit Zed!, certifié EAL3+ en mai 2016 dans sa version 6.1 build 2120 et pour lequel une vulnérabilité a été découverte 2 ans plus tard (CVE-2018-16518 Site de PrimX). La version 6.1.2226 corrigeant cette vulnérabilité n’est quant à elle pas certifiée. Alors que faut-il faire ? Mettre la dernière version à jour et perdre la certification ou rester sur un produit vulnérable mais certifié ?

Voilà toute l’ambiguïté des certifications, le process étant long et complexe, il n’est pas possible de faire certifier chaque nouvelle version. En effet il est possible que les nouvelles versions introduisent de nouvelles vulnérabilités mais par ailleurs en corrigent d’autres. Alors que faire ?

Dans un premier temps, il nous semble important que ces produits soient mis en œuvre par des professionnels habitués aux risques cyber, qui en maitrisent tous les contours et à même de conseiller les clients sur le rapport bénéfice/risque des solutions à apporter. L’architecte doit prendre en compte les recommandations de l’ANSSI, le concept de défense en profondeur et la capacité/maturité du client sur les risques cyber. En effet le maintien en condition de sécurité par des audits et mises à jour est indispensable. Ainsi la sécurité d’une installation ne se dégradera pas au fil des mois comme cette clôture jamais rénovée et complétement rongée par la rouille.