Arborescence des pages

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

...

En conclusion, gardez à l'esprit qu'en tant que communauté et développeurs d'ESUP-SGC, nous n'avons aucun intérêt à vous convaincre de passer à ESUP-SGC si vous n'avez tout simplement pas l'envie, la motivation, la volonté d'adhérer à ce projet ; on serait très embêtés (en plus d'être étonnés tout de même (clin d'œil) ) qu'ESUP-SGC vous donne moins de satisfaction que votre ancienne solution !

Est-ce qu'ESUP-SGC est configurable pour s'adapter à mon établissement ? Combien et quels établissements l'utilisent actuellement ?

ESUP-SGC 

De quel matériel ai-je besoin ?

...

Bloc de code
languagetext
themeRDark
accessRestrictionWSRestApi=hasIpAddress('127.0.0.1') or hasIpAddress('192.168.1.39') or hasIpAddress('192.168.22.0/24')

Comment passer la carte d'un état à un autre via web-service ?

Le passage d'un état à un autre d'une carte peut se faire via l'appel à un webservice. Cet appel ressemble à ceci :

Bloc de code
languagebash
themeRDark
curl -d "etat=REQUEST_CHECKED" https://esup-sgc.univ-ville.fr/wsrest/api/setCardEtat/1818864

1818864 est l'id de la carte. Cet appel retourne true ou false suivant que la commande a réussi ou échoué.

Ainsi, si on veut par exemple demander une carte par web-service et valider aussitôt cette demande, il faudra appeler le web service de la question précédente suivie de celui-ci.

Lors de cet appel au WebService, les paramètres possibles correspondent en réalité à l'ensemble des attributs d'une Carte au sens Java. On peut déduire ces paramètres du code Java lui-même donné ici : https://github.com/EsupPortail/esup-sgc/blob/master/src/main/java/org/esupportail/sgc/domain/Card.java

 Exemple d'appel WEB-Service spécifiant le CSN et le numéro de contrôle d'accès dans le cadre où on souhaiterait 'importer' des cartes éditées par une autre solution Exemple en python :

Bloc de code
languagepybash
themeRDark
curl -F "desfireIds[access-control]=12340000000125" -F "csn=0479CDE56F1490"  -F "eppn=toto@univ-ville.fr" -F "difPhotoTransient=true" -F "crousTransient=true" -F "europeanTransient=true" -F "PhotoFile.file=@/tmp/toto.jpeg" https://esup-sgc.univ-ville.fr/wsrest/api

Notez qu'on peut donc ici spécifier l'etat dans lequel on souhaiterait voir la carte éditée (-F "etat=ENCODED" par exemple) mais suivre le cycle de vie de la carte peut cependant être préférable pour pouvoir
bénéficier des appels de fonctions entre les transitions de la carte (positionnement des rectos imprimés, envoi d'email, activation de la carte) : d'autant qu'une fois la demande créee, on peut aussi passer les changements d'états par WS également.

Comment passer la carte d'un état à un autre via web-service ?

Le passage d'un état à un autre d'une carte peut se faire via l'appel à un webservice. Cet appel ressemble à ceci :

Bloc de code
languagebash
themeRDark
curl -d "etat=REQUEST_CHECKED" https://esup-sgc.univ-ville.fr/wsrest/api/setCardEtat/1818864

1818864 est l'id de la carte. Cet appel retourne true ou false suivant que la commande a réussi ou échoué.

Ainsi, si on veut par exemple demander une carte par web-service et valider aussitôt cette demande, il faudra appeler le web service de la question précédente suivie de celui-ci.

Exemple en python :


Bloc de code
languagepy
themeRDark
#!/usr/bin/env python3                                                                                        #!/usr/bin/env python3                                                                                                                                                                          
# -*- coding: utf-8 -*-                                                                                                                                                                       

import requests

api_url = "https://esup-sgc.univ-ville.fr/wsrest/api"
response = requests.post(api_url, data={"eppn":"toto@univ-ville.fr"}, files={"PhotoFile.file":("photo-toto.png", open("/tmp/photo-toto.png","rb"), "image/png")})
card_id = response.text
response = requests.post("%s/setCardEtat/%s" % (api_url, card_id), data={"etat":"REQUEST_CHECKED"})
print(response.text)

...

Bloc de code
languagebash
themeRDark
curl -d "etat=ENCODED" -d "csn=061D72BB3E7280" -d "csn=061D72BB3E7280" https://esup-sgc.univ-ville.fr/wsrest/api/setCardEtat/205https://esup-sgc.univ-ville.fr/wsrest/api/setCardEtat/205

Notez qu'on peut également positionner ce CSN et tout autre attribut de la carte dès la création de la carte par Web-Service - voir à ce propos la question ci-avant "Comment faire une demande de carte en utilisant le webservice proposé par ESUP-SGC ?".

De quelles données utilisateur issues du SI esup-sgc a besoin  ?

...

Côté esup-sgc, le contrôle d'accès au web-service des photos se fait via la propriété de accessRestrictionWSRestPhoto de security.properties où on propose par défaut de lister les IPs via des expressions type hasIpAddress('127.0.0.1') or hasIpAddress('0:0:0:0:0:0:0:1') or ...
Il faut donc y ajouter ici l'IP du serveur où est installé esup-mdw ; notez qu'esup-mdw récupère véritablement les photos pour les présenter à l'utilisateur, la sécurité d'accès des photos est donc vis-à-vis de l'utilisateur opéré directement par esup-mdw.

Comment récupérer les photos par script ?

Esup-sgc propose une API permettant de récupérer les photos.

Pour pouvoir l'utiliser, l'utilisateur opéré directement par esup-mdw.

Comment récupérer les photos par script ?

Esup-sgc propose une API permettant de récupérer les photos.

...

'IP du client doit être référencé dans accessRestrictionWSRestPhoto, fichier security.properties

    • Récupérer la dernière photo en date non rejetée  d'un utilisateur :
Bloc de code
languagebash
themeRDark
wget 'http://localhost:8080/wsrest/photo/joe@univ-ville.fr/photo'
  • Récupérer la dernière photo en date dans un état donné d'un utilisateur : 

    Bloc de code
    languagebash
    themeRDark
    wget 'http://localhost:8080/wsrest/photo/joe@univ-ville.fr/photo?cardEtat=ENABLED'
    

    (état activé ici)

  • Récupérer la dernière photo en date

  • non rejetée 
  • dans un état donné d'un utilisateur après une date précisée (renvoie un code http 304 si la photo en question n'a pas été modifiée depuis cette date) : 

Bloc de code
languagebash
themeRDark
wget 'http://localhost:8080/wsrest/photo/joe@univ-ville.fr/photo'

...

/photo/joe@univ-ville.fr/photo?cardEtat=ENABLED&dateEtatAfter=2018-06-19'

Pour prendre en compte le choix de l'utilisateur de diffuser ou non sa photo, on peut faire les mêmes requêtes avec /restrictedPhoto en lieu et place de /photo :

Bloc de code
languagebash
themeRDark
wget 'http://localhost:8080/wsrest/photo/joe@univ-ville.fr/

...

restrictedPhoto?cardEtat=ENABLED'

(état activé ici)

Comment récupérer par script / API / SQL les données et cartes d'un ou plusieurs utilisateurs ?

Esup-sgc propose une API permettant de récupérer les données et carte d'un ou plusieurs utilisateurs.

Pour pouvoir utiliser ce web service, l'IP du client doit être référencé dans accessRestrictionWSRestApi, fichier security.properties

...

Bloc de code
languagebash
themeRDark
wget 'http://localhost:8080/wsrest/photo/joe@univapi/get?eppn=toto@univ-ville.fr/photo?cardEtat=ENABLED&dateEtatAfter=2018-06-19'
&eppn=titi@univ-ville.fr'

La récupération du CSN de la carte active peut se faire ainsi par exemple Pour prendre en compte le choix de l'utilisateur de diffuser ou non sa photo, on peut faire les mêmes requêtes avec /restrictedPhoto en lieu et place de /photo :

Bloc de code
languagebash
themeRDark
wgetcurl -s 'http://localhost:8080/wsrest/photo/joe@univ-ville.fr/restrictedPhoto?cardEtat=ENABLED'

Comment récupérer par script les données et cartes d'un ou plusieurs utilisateurs ?

Esup-sgc propose une API permettant de récupérer les données et carte d'un ou plusieurs utilisateurs.

Pour pouvoir l'utiliser, l'IP du client doit être référencé dans accessRestrictionWSRestApi, fichier security.properties

api/get?eppn=toto@univ-ville.fr' | jq '.[] | select(.eppn == "toto@univ-ville.fr") | .cards[] | select(.etat == "ENABLED") | .csn'

Notez qu'on peut aussi facilement récupérer ces mêmes données via une simple requête SQL dont la base de données est simple et stable :

Bloc de code
languagesql
themeRDark
select csn from card where eppn='toto@univ-ville.fr' and etat='ENABLED';
Bloc de code
languagebash
themeRDark
wget 'http://localhost:8080/wsrest/api/get?eppn=toto@univ-ville.fr&eppn=titi@univ-ville.fr'

Quelle version de Java puis-je utiliser ?

...

Bloc de code
languagesql
themeRDark
esupsgc=# UPDATE card SET textsearchable_index_col = UPDATE card SET textsearchable_index_col = setweight(to_tsvector('simple', coalesce(card.eppn,'')), 'B')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.name,''),'-',' ')), 'A')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.firstname,''),'-',' ')), 'B')
 || setweight(to_tsvector('simple', coalesce(carduser_account.eppnemail,'')), 'B')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.namesupann_emp_id,''),'-',' ')), 'AB')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.firstnamesupann_etu_id,''),'-',' ')), 'B')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.emailsupann_entite_affectation_principale,''),'-',' ')), 'BC')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.supann_emp_id(card.csn,''),'-',' ')), 'C')
 || setweight(to_tsvector('simple', replace(coalesce(card.full_text,''),'-',' ')), 'BD')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.supannfull_etu_idtext,''),'-',' ')), 'BD')
 || setweight(to_tsvector('simple', replace(coalesce( FROM user_account where card.eppn=user_account.supann_entite_affectation_principale,''),'-',' ')), 'C')
 || setweight(to_tsvector('simple', replace(coalesce(card.csn,''),'-',' ')), 'C')
 || setweight(to_tsvector('simple', replace(coalesce(card.full_text,''),'-',' ')), 'D')
 || setweight(to_tsvector('simple', replace(coalesce(user_account.full_text,''),'-',' ')), 'D')
 FROM user_account where card.eppn=user_account.eppn;

esupsgc=# alter table user_account enable trigger tsvectorupdateuser;
esupsgc=# alter table card enable trigger tsvectorupdate;

ESUP-NFC-TAG

Je n'ai pas de groupes dans ldap, est-ce que je peux plutôt utiliser des filtres pour affecter les rôles dans l'application ESUP-NFC-TAG ?

Même si l'usage de groupes ldap, notamment via l'usage de Grouper, est conseillé (c'est ce que propose la configuration par défaut et c'est ce qui est utilisé dans la VM de démonstration), il est effectivement possible d'utiliser en lieu et place des filtres ldap.

eppn;

esupsgc=# alter table user_account enable trigger tsvectorupdateuser;
esupsgc=# alter table card enable trigger tsvectorupdate;


ESUP-NFC-TAG

Je n'ai pas de groupes dans ldap, est-ce que je peux plutôt utiliser des filtres pour affecter les rôles dans l'application ESUP-NFC-TAG ?

Même si l'usage de groupes ldap, notamment via l'usage de Grouper, est conseillé (c'est ce que propose la configuration par défaut et c'est ce qui est utilisé dans la VM de démonstration), il est effectivement possible d'utiliser en lieu et place des filtres ldap.

Pour ce faire, dans applicationContext-security.xml on modifiera 

Bloc de code
languagexml
themeRDark
	<beans:bean id="groupService" class="org.esupportail.nfctag.security.LdapGroupService">
		<beans:property name="ldapTemplate" ref="ldapTemplate"/>
		<beans:property name="groupSearchBase" value="ou=groups" />
		<beans:property name="groupSearchFilter" value="member={0}"/>
		<beans:property name="memberSearchBase" value="ou=people"/>
		<beans:property name="memberSearchFilter" value="memberOf={0}"/>
	</beans:bean>

par quelque chose du type : 

Bloc de code
languagexml
themeRDark
	<beans:bean id="groupService" class="org.esupportail.nfctag.security.LdapFilterGroupService">
		<beans:property name="ldapTemplate" ref="ldapTemplate"/>
		<beans:property name="ldapFiltersGroups">
			<util:map>
				<beans:entry key="eduPersonPrincipalName=joe@univ-ville.fr" value="esup-nfc-admins"/>
				<beans:entry key="eduPersonPrincipalName=jack@univ-ville.fr" value="esup-nfc-supervisors"/>
			</util:map>
		</beans:property>
	</beans:bean>

C'est ensuite ces noms de groupes ainsi déifinis ('esup-sgc-admins', 'esup-nfc-supervisors') qui peuvent être utilisés au niveau du bean nfcMappingGroupesRoles pour définir les rôles de chacun : Pour ce faire, dans applicationContext-security.xml on modifiera 

Bloc de code
languagexml
themeRDark
	<beans<util:beanmap id="groupService" class="org.esupportail.nfctag.security.LdapGroupService">
		<beans:property name="ldapTemplate" ref="ldapTemplate"/>
nfcMappingGroupesRoles">
			<beans:propertyentry namekey="groupSearchBaseesup-nfc-admins" value="ou=groupsROLE_ADMIN" />
			<beans:propertyentry namekey="groupSearchFilteresup-nfc-supervisors" value="member={0}"/>
		<beans:property name="memberSearchBase" value="ou=people"/>
		<beans:property name="memberSearchFilter" value="memberOf={0}"/>
	</beans:bean>

par quelque chose du type : 

Bloc de code
languagexml
themeRDark
	<beans:bean id="groupService" class="org.esupportail.nfctag.security.LdapFilterGroupService">
		<beans:property name="ldapTemplate" ref="ldapTemplate"/>
		<beans:property name="ldapFiltersGroups">
			<util:map>
				<beans:entry key="eduPersonPrincipalName=joe@univ-ville.fr" value="esup-nfc-admins"/>
				<beans:entry key="eduPersonPrincipalName=jack@univ-ville.fr" value="esup-nfc-supervisors"/>
			</util:map>
		</beans:property>
	</beans:bean>

C'est ensuite ces noms de groupes ainsi déifinis ('esup-sgc-admins', 'esup-nfc-supervisors') qui peuvent être utilisés au niveau du bean nfcMappingGroupesRoles pour définir les rôles de chacun : 

Bloc de code
languagexml
themeRDark
	<util:map id="nfcMappingGroupesRoles">
			<beans:entry key="esup-nfc-admins" value="ROLE_ADMIN" />
			<beans:entry key="esup-nfc-supervisors" value="ROLE_SUPERVISOR" />
	</util:map>

Nous souhaitons mettre en place l'encodage des cartes pour du contrôle d'accès basé sur Desfire

ESUP-SGC et ESUP-NFC-TAG permettent cette mise en oeuvre de l'encodage Desfire pour des usages très sécurisés comme le contrôle d'accès.

C'est la partie la plus délicate de l'installation d'une telle plateforme dans un établissement ou un groupement d'établissements : Desfire est assez éloignée de nos coeurs de métiers dans nos SI !

Pour une telle mise en oeuvre, nous vous conseilleurs de prendre connaissance et lire attentivement les documentations suivantes sur les espaces ESUP-SGC / ESUP-NFC-TAG : 

Avant toute chose cependant, assurez-vous d'être en possession de la "master key" de vos cartes !

Sans cette clef, vous n'aurez pas  la possibilité d'ajouter des "applications Mifare Desfire" sur vos cartes.

J'ai besoin de connaître la master key de ma carte ?

La "master key" de la carte Mifare Desfire est une clef (DES ou AES) qui permet d'ajouter des "applications Desfire" pour du contrôle d'accès ou tout autre type d'usage.

Ces applications Desfire peuvent être positionnées par esup-nfc-tag si vous avez en votre possession la master key de la carte.

Pour plus d'information sur NFC et Mifare Desfire, vous pouvez consulter la page wiki Tags NFC - getting started.

Vous avez donc besoin de connaitre effectivement la master key de votre carte uniquement si vous souhaitez ajouter des applications Mifare Desfire dans vos cartes.

Cependant nous vous conseillons fortement d'avoir la main sur vos propres cartes, c'est à dire de faire en sorte d'avoir en votre possession la master key de vos cartes.

Quelle est la master key de ma carte ?

Les cartes Mifare Desfire vierges ont une master key en DES à 0, sa représentation en hexa est 0000000000000000.

Dès qu'on encode une carte, il est d'usage de prendre la main sur la carte et de modifier cette master-key par défaut par une clef différente, usuellement en AES (car plus sécurisé).

Si vos cartes sont pré-encodées ou ont été encodées par un sous-traitant, demandez leur de positionner une master-key unique pour l'ensemble de vos cartes (et d'en avoir connaissance).

Comment avoir la master-key sur des cartes pré-encodées CROUS ?

On conseille de faire pré-encoder vos cartes avec l'application CROUS/IZLY, cela vous évite de manipuler des clefs sam, dll windows, etc.

Au moment du pré-encodage, pour des questions de sécurité, une master-key est positionnée par l'entreprise qui encode vos cartes.

Par défaut cette master-key est diversifiée, non unique pour l'ensemble de vos cartes, et fonction de la clef SAM crous ; en d'autres termes cette master key vous est inconnue et vous ne pouvez pas alors ajouter de nouvelles applications avec votre esup-sgc / esup-nfc-tag.

Aussi, on vous recommande fortement de demander à positionner une master-key sur vos cartes.  Pour ce faire, vous devez transmettre cette clef en suivant la procédure "MasterKeyGenerator : Génération & communication de clés" mise au point par le CROUS : téléchargement ici.

Cette procédure, accompagnée d'un programme java (jar) vous permet d'obtenir votre master-key à positionner et 3 fichiers supplémentaires, qui assemblés, permettent au prestataire de positionner la master-key sur vos cartes (sans pour autant en avoir connaissance).

Ces 3 fichiers doivent être envoyés par mail chiffrés (c'est le prestataire qui vous donne les 3 mails et 3 clefs de chiffrement respectives à utiliser pour ce faire).

Quels types de cartes ESUP-NFC-TAG est-il capable d'encoder ?

ESUP-NFC-TAG propose l'encodage (et décodage/lecture sécurisée) des cartes Mifare Desfire ; c'est à dire les cartes actuellement les plus utilisées dans nos établissements car considérées comme les plus sécurisées et permettant ainsi de proposer en confiance un moyen de paiement et de contrôle d'accès.

De fait ESUP-NFC-TAG supporte à la fois les cartes Mifare Desfire EV1, Mifare Desfire EV2, Mifare Desfilre EV3.

Mifare Desfire EV3 étant la dernière en date actuellement (NDR : au 11/03/2022), ce sont ces cartes qui sont achetées et utilisées par les établissements actuellement (via notamment le marché cartes multiservices porté par le CNOUS et le CNCEU).

Peut-on utiliser esup-nfc-tag pour modifier la master key d'une carte

Dans certains cas (par exemple l'utilisation de carte vièrge dans le cadre du SGC) il peut être nécessaire de positionner une cle master sur une carte avant de pouvoir l'encoder normalament (ceci sans passer par les différents contrôles proposés par esup-nfc-tag). En effet esup-nfc-tag propose, dans son fonctionnement le plus courant, de contrôler l'existence de la carte puis de vérifier sa validité dans le système d'information (tagIdCheck et validateTag).

L'idée ici est de shunter ces deux étapes en utilisant les implémentations Dummy proposées dans esup-nfc-tag-server. Ces implémentations valident systématiquement les tags en retournant "true" quelle que soit la carte badgée.

Il est donc possible de créer un bean AppliExtApi reprenant l'implémantation AppliExtDummy en précisant un nom de salle (location) personnalisé.

De plus il faut déclarer un DesfireWriteConfig et un DesfireTag qui décrivent les actions à opérer sur la carte.

Dans ce cas il faut donc ajouter la configuration suivante:

applicationContext-desfire.xml (pour modifier la master key par defaut par une clé AES)

Bloc de code
languagexml
themeRDark
<bean id="desfireChangeMasterKeyTagEsupSgc" class="org.esupportail.nfctag.beans.DesfireTag" p:formatBeforeWrite="false" p:keyStart="0000000000000000" p:keyTypeStart="DES" p:keyFinish="12345678901234567890123456789012" p:keyTypeFinish="AES" p:keyVersionFinish="01">   
</bean>
 
<bean id="desfireAuthConfigChangeKeyMasterEsupSgc" class="org.esupportail.nfctag.service.api.impl.DesfireWriteConfig">
    <property name="desfireTag" ref="desfireChangeMasterKeyTagEsupSgc" />
    <property name="description" value="Changement de la Master Key"/>
</bean>

applicationContext-custom.xml (ajout d'une application dummy dediée)

Bloc de code
languagexml
themeRDark
<bean id="dummyChangeMasterKeyExtApi" class="org.esupportail.nfctag.service.api.impl.AppliExtDummy">
   	<property name="description" value="Changement Master Key"/>
   	<property name="locationsNames">
   		<util:list>
   			<value>Change Master Key</value>
   		</util:list>
   	</property>
</bean>

Puis il faut créer une application esup-nfc-tag au niveau de l'IHM en utilisant les paramètres suivants :

  • Nom : Change Master Key
  • Configuration NFC : Changement de la Master Key
  • Application externe : Changement Master Key

Quelle est la différence entre Mifare Desfire EV1, Mifare Desfire EV2 ou encore Mifare Desfire EV3 ?

Ces 3 technologies correspondent à des évolutions de Mifare Desfire. En prime abord, il faut retenir que NXP assure une compatibilité descendante de ses cartes vis-à-vis des applicatifs compatibles Mifare Desfire : en bref et rapidement, un contrôle d'accès compatible et codé au départ pour prendre en charge le protocole Mifare Desfire EV1 pourra utiliser des cartes Mifare Desfire EV3.

Pus précisément, parlons par exemple de la différence entre EV1 et EV2 : Mifare Desfire EV2 fait suite à Mifare Desfire EV1. 

EV2 est présentée comme plus sécurisée que EV1.

Il faut cependant distinguer la carte du protocole utilisé.

Aussi retenons que :

  • EV2 est donc à la fois des cartes EV2 et un nouveau protocole EV2.
  • Les cartes Desfire EV2 supportent le protocole EV1 et le protocole EV2.
  • Les cartes Desfire EV1 ne supportent que le protocole EV1
  • Le protocole EV2 est plus sécurisé (et plus complexe du coup) que le protocole EV1.
  • Les nouvelles possibilités offertes par les cartes EV2 (application déléguée et libération de la mémoire) 
    •  ne sont pas supportées par les cartes EV1
    • mais peuvent être codées avec le protocole EV1.
  • ESUP-SGC au travers d'ESUP-NFC-TAG utilise le protocole EV1 (et est donc compatible avec les cartes EV1 et EV2).

Codées avec ESUP-SGC / ESUP-NFC-TAG (via le protocole EV1), l'usage des cartes EV2 avec le protocole EV2 (par exemple au travers du contrôle d'accès) apporteraient de fait une plus grande sécurité que son usage au travers du protocole EV1.
Cf la documentation NXP https://www.nxp.com/docs/en/fact-sheet/MIFARE-DESFIRE-EV2-FS.pdf : "Proximity Check protects against relay attacks".

ESUP-SGC / ESUP-NFC-TAG, dans le cadre du projet de Carte Etudiante Européenne devrait également prochainement (en cours d'implémentation) supporter au niveau de l'encodage les nouvelles possibilités offertes par EV2, à savoir le support des applications déléguées et de la libération de la mémoire.

Concernant EV3 (et toutes autres versions qui pourraient suivre), la logique de rétrocompatibilité est la même.

Est-ce que ESUP-SGC peut coder la DEUInfo de la care étudiante européenne ?

Oui, esup-sgc peut être configuré pour coder l'application DEUInfo dans un carte Mifare Desfire. 

La documentation pour ce faire est donnée ici : Carte étudiante européenne

Est-ce qu'on peut demander à un prestataire de se charger de coder la DEUInfo ?

Avant la version 2.0, l'implémentation d'esup-sgc faisait qu'on ne poiuvait pas déléguer cette partie à un prestataire.

La DEUInfo (Data European University Info) consiste notamment à coder l'ESCN (European Student Card Number) dans la carte.

Le QRCode utilisé par esup-sgc correspond à l'ESCN inclu dans une url en esc.gg

Le fonctionnement d'esup-sgc (lorsqu'il imprime et encode en 2 temps) rattache ce qui est imprimé à la partie électronique en utilisant le QR Code d'une part et le CSN d'autre part.

De fait l'association escn/csn ne peut pas se faire en dehors d'esup-sgc, et donc les établissements utilisant esup-sgc avec l'édition en 2 temps ne peuvent pas demander à un prestataire de pré-encoder la DEUInfo pour eux.

ROLE_SUPERVISOR" />
	</util:map>

Nous souhaitons mettre en place l'encodage des cartes pour du contrôle d'accès basé sur Desfire

ESUP-SGC et ESUP-NFC-TAG permettent cette mise en oeuvre de l'encodage Desfire pour des usages très sécurisés comme le contrôle d'accès.

C'est la partie la plus délicate de l'installation d'une telle plateforme dans un établissement ou un groupement d'établissements : Desfire est assez éloignée de nos coeurs de métiers dans nos SI !

Pour une telle mise en oeuvre, nous vous conseilleurs de prendre connaissance et lire attentivement les documentations suivantes sur les espaces ESUP-SGC / ESUP-NFC-TAG : 

Avant toute chose cependant, assurez-vous d'être en possession de la "master key" de vos cartes !

Sans cette clef, vous n'aurez pas  la possibilité d'ajouter des "applications Mifare Desfire" sur vos cartes.

J'ai besoin de connaître la master key de ma carte ?

La "master key" de la carte Mifare Desfire est une clef (DES ou AES) qui permet d'ajouter des "applications Desfire" pour du contrôle d'accès ou tout autre type d'usage.

Ces applications Desfire peuvent être positionnées par esup-nfc-tag si vous avez en votre possession la master key de la carte.

Pour plus d'information sur NFC et Mifare Desfire, vous pouvez consulter la page wiki Tags NFC - getting started.

Vous avez donc besoin de connaitre effectivement la master key de votre carte uniquement si vous souhaitez ajouter des applications Mifare Desfire dans vos cartes.

Cependant nous vous conseillons fortement d'avoir la main sur vos propres cartes, c'est à dire de faire en sorte d'avoir en votre possession la master key de vos cartes.

Quelle est la master key de ma carte ?

Les cartes Mifare Desfire vierges ont une master key en DES à 0, sa représentation en hexa est 0000000000000000.

Dès qu'on encode une carte, il est d'usage de prendre la main sur la carte et de modifier cette master-key par défaut par une clef différente, usuellement en AES (car plus sécurisé).

Si vos cartes sont pré-encodées ou ont été encodées par un sous-traitant, demandez leur de positionner une master-key unique pour l'ensemble de vos cartes (et d'en avoir connaissance).

Comment avoir la master-key sur des cartes pré-encodées CROUS ?

On conseille de faire pré-encoder vos cartes avec l'application CROUS/IZLY, cela vous évite de manipuler des clefs sam, dll windows, etc.

Au moment du pré-encodage, pour des questions de sécurité, une master-key est positionnée par l'entreprise qui encode vos cartes.

Par défaut cette master-key est diversifiée, non unique pour l'ensemble de vos cartes, et fonction de la clef SAM crous ; en d'autres termes cette master key vous est inconnue et vous ne pouvez pas alors ajouter de nouvelles applications avec votre esup-sgc / esup-nfc-tag.

Aussi, on vous recommande fortement de demander à positionner une master-key sur vos cartes.  Pour ce faire, vous devez transmettre cette clef en suivant la procédure "MasterKeyGenerator : Génération & communication de clés" mise au point par le CROUS : téléchargement ici.

Cette procédure, accompagnée d'un programme java (jar) vous permet d'obtenir votre master-key à positionner et 3 fichiers supplémentaires, qui assemblés, permettent au prestataire de positionner la master-key sur vos cartes (sans pour autant en avoir connaissance).

Ces 3 fichiers doivent être envoyés par mail chiffrés (c'est le prestataire qui vous donne les 3 mails et 3 clefs de chiffrement respectives à utiliser pour ce faire).

Quels types de cartes ESUP-NFC-TAG est-il capable d'encoder ?

ESUP-NFC-TAG propose l'encodage (et décodage/lecture sécurisée) des cartes Mifare Desfire ; c'est à dire les cartes actuellement les plus utilisées dans nos établissements car considérées comme les plus sécurisées et permettant ainsi de proposer en confiance un moyen de paiement et de contrôle d'accès.

De fait ESUP-NFC-TAG supporte à la fois les cartes Mifare Desfire EV1, Mifare Desfire EV2, Mifare Desfilre EV3.

Mifare Desfire EV3 étant la dernière en date actuellement (NDR : au 11/03/2022), ce sont ces cartes qui sont achetées et utilisées par les établissements actuellement (via notamment le marché cartes multiservices porté par le CNOUS et le CNCEU).

Peut-on utiliser esup-nfc-tag pour modifier la master key d'une carte

Dans certains cas (par exemple l'utilisation de carte vièrge dans le cadre du SGC) il peut être nécessaire de positionner une cle master sur une carte avant de pouvoir l'encoder normalament (ceci sans passer par les différents contrôles proposés par esup-nfc-tag). En effet esup-nfc-tag propose, dans son fonctionnement le plus courant, de contrôler l'existence de la carte puis de vérifier sa validité dans le système d'information (tagIdCheck et validateTag).

L'idée ici est de shunter ces deux étapes en utilisant les implémentations Dummy proposées dans esup-nfc-tag-server. Ces implémentations valident systématiquement les tags en retournant "true" quelle que soit la carte badgée.

Il est donc possible de créer un bean AppliExtApi reprenant l'implémantation AppliExtDummy en précisant un nom de salle (location) personnalisé.

De plus il faut déclarer un DesfireWriteConfig et un DesfireTag qui décrivent les actions à opérer sur la carte.

Dans ce cas il faut donc ajouter la configuration suivante:

applicationContext-desfire.xml (pour modifier la master key par defaut par une clé AES)

Bloc de code
languagexml
themeRDark
<bean id="desfireChangeMasterKeyTagEsupSgc" class="org.esupportail.nfctag.beans.DesfireTag" p:formatBeforeWrite="false" p:keyStart="0000000000000000" p:keyTypeStart="DES" p:keyFinish="12345678901234567890123456789012" p:keyTypeFinish="AES" p:keyVersionFinish="01">   
</bean>
 
<bean id="desfireAuthConfigChangeKeyMasterEsupSgc" class="org.esupportail.nfctag.service.api.impl.DesfireWriteConfig">
    <property name="desfireTag" ref="desfireChangeMasterKeyTagEsupSgc" />
    <property name="description" value="Changement de la Master Key"/>
</bean>

applicationContext-custom.xml (ajout d'une application dummy dediée)

Bloc de code
languagexml
themeRDark
<bean id="dummyChangeMasterKeyExtApi" class="org.esupportail.nfctag.service.api.impl.AppliExtDummy">
   	<property name="description" value="Changement Master Key"/>
   	<property name="locationsNames">
   		<util:list>
   			<value>Change Master Key</value>
   		</util:list>
   	</property>
</bean>

Puis il faut créer une application esup-nfc-tag au niveau de l'IHM en utilisant les paramètres suivants :

  • Nom : Change Master Key
  • Configuration NFC : Changement de la Master Key
  • Application externe : Changement Master Key

Quelle est la différence entre Mifare Desfire EV1, Mifare Desfire EV2 ou encore Mifare Desfire EV3 ?

Ces 3 technologies correspondent à des évolutions de Mifare Desfire. En prime abord, il faut retenir que NXP assure une compatibilité descendante de ses cartes vis-à-vis des applicatifs compatibles Mifare Desfire : en bref et rapidement, un contrôle d'accès compatible et codé au départ pour prendre en charge le protocole Mifare Desfire EV1 pourra utiliser des cartes Mifare Desfire EV3.

Pus précisément, parlons par exemple de la différence entre EV1 et EV2 : Mifare Desfire EV2 fait suite à Mifare Desfire EV1. 

EV2 est présentée comme plus sécurisée que EV1.

Il faut cependant distinguer la carte du protocole utilisé.

Aussi retenons que :

  • EV2 est donc à la fois des cartes EV2 et un nouveau protocole EV2.
  • Les cartes Desfire EV2 supportent le protocole EV1 et le protocole EV2.
  • Les cartes Desfire EV1 ne supportent que le protocole EV1
  • Le protocole EV2 est plus sécurisé (et plus complexe du coup) que le protocole EV1.
  • Les nouvelles possibilités offertes par les cartes EV2 (application déléguée et libération de la mémoire) 
    •  ne sont pas supportées par les cartes EV1
    • mais peuvent être codées avec le protocole EV1.
  • ESUP-SGC au travers d'ESUP-NFC-TAG utilise le protocole EV1 (et est donc compatible avec les cartes EV1 et EV2).

Codées avec ESUP-SGC / ESUP-NFC-TAG (via le protocole EV1), l'usage des cartes EV2 avec le protocole EV2 (par exemple au travers du contrôle d'accès) apporteraient de fait une plus grande sécurité que son usage au travers du protocole EV1.
Cf la documentation NXP https://www.nxp.com/docs/en/fact-sheet/MIFARE-DESFIRE-EV2-FS.pdf : "Proximity Check protects against relay attacks".

ESUP-SGC / ESUP-NFC-TAG, dans le cadre du projet de Carte Etudiante Européenne devrait également prochainement (en cours d'implémentation) supporter au niveau de l'encodage les nouvelles possibilités offertes par EV2, à savoir le support des applications déléguées et de la libération de la mémoire.

Concernant EV3 (et toutes autres versions qui pourraient suivre), la logique de rétrocompatibilité est la même.

Peut-on utiliser l'application Desfire Crous/Izly via esup-nfc-tag et plus généralement dans nos services institutionnels comme le servie d'impression ou le contrôle d'accès ?

Si esup-nfc-tag (allié à esup-sgc) sait lancer la DLL CROUS/Izly pour écrire l'application crous/izly (on recommande cependant l'achat de cartes pré-encodées), esup-nfc-tag ne propose pas de lire l'application Desfire CROUS/Izly.

Il faut en fait considérer que l'application Desfire CROUS/Izly, même si elle est écrite sur vos cartes (et éventuellement par vous-même), ne vous appartient pas et ne devrait pas être utilisée en dehors du contexte précis pour lequel elle a été conçue (services du CROUS).

Cela exclut donc de fait l'usage de l'application Desfire CROUS/Izly au travers d'esup-nfc-tag, mais aussi au travers de votre service d'impression, de votre contrôle d'accès, etc.

Si vous souhaitez utiliser une application Desfire sur vos cartes pour le contrôle d'accès ou tout autre service, vous devez en écrire une (ou plusieurs) vous-même, qui vous appartient ; on vous y encourage, cela constitue en partie la raison d'être d'esup-nfc-tag allié à esup-sgc !

Est-ce que ESUP-SGC peut coder la DEUInfo de la care étudiante européenne ?

Oui, esup-sgc peut être configuré pour coder l'application DEUInfo dans un carte Mifare Desfire. 

La documentation pour ce faire est donnée ici : Carte étudiante européenne

Est-ce qu'on peut demander à un prestataire de se charger de coder la DEUInfo ?

Avant la version 2.0, l'implémentation d'esup-sgc faisait qu'on ne poiuvait pas déléguer cette partie à un prestataire.

La DEUInfo (Data European University Info) consiste notamment à coder l'ESCN (European Student Card Number) dans la carte.

Le QRCode utilisé par esup-sgc correspond à l'ESCN inclu dans une url en esc.gg

Le fonctionnement d'esup-sgc (lorsqu'il imprime et encode en 2 temps) rattache ce qui est imprimé à la partie électronique en utilisant le QR Code d'une part et le CSN d'autre part.

De fait l'association escn/csn ne peut pas se faire en dehors d'esup-sgc, et donc les établissements utilisant esup-sgc avec l'édition en 2 temps ne peuvent pas demander à un prestataire de pré-encoder la DEUInfo pour eux.

Avec l'édition en 1 temps disponible dans esup-sgc 2, cette limitation est cependant théoriquement levée.

Comment renseigner l'application Desfire ID AID pour la mise en place d'une application Desfire de contrôle d'accès ?

Techniquement, il est possible de choisir soi-même un AID quelconque qui sera l'identificant de votre application de contrôle d'accès. Vous positionnerez alors les fichiers et clefs dans cette application.

Cependant, il est d'usage de s'adresser à NXP pour obtenir un AID qui vous soit propre. Cette procédure est gratuite et la société NXP s'assure ainsi de distribuer un AID unique et réservé pour l'usage de chacun. Pour ce faire, il faut remplir l'annexe A du document AN10787.pdf et l'envoyer à NXP via support.docstore@nxp.com.

Plus d'information à ce propos sur le document AN11909.pdf : How to create an Installation IDentifier (IID)

Le retour Contrôle d'accès à l'Université de Rouen Normandie dans ce même wiki vous donnera aussi des explications et cas d'usage sur l'encodage d'une application Desfire de contrôle d'accès dans le contexte d'esup-sgc/esup-nfc-tagAvec l'édition en 1 temps disponible dans esup-sgc 2, cette limitation est cependant théoriquement levée.

Est-ce qu'esup-sgc peut positionner des DAM keys sur les cartes supportant Mifare DesFire EV2 ?

...