Cadre de sécurité coopératif des STI: normes
et progrès de la mise en œuvre en Europe
Brigitte Lonc 1 et Pierpaolo Cincilla 2
1DEA-SM - Département Ingénierie Système Alliance, Renault, Guyancourt, France. Courriel: brigitte.lonc@renault.fr
2 Institut de recherche technologique SystemX, Palaiseau, France. Courriel: pierpaolo.cincilla@irt-systemx.fr
Abstrait —Un certain nombre d'organisations de normalisation et
Les projets européens ont traité des questions de sécurité et de confidentialité dans
les systèmes de transport intelligents coopératifs (C – ITS). Dans cet article, nous
présentons les récentes activités de normalisation et les implémentations de
services de sécurité dans diverses applications de conduite coopérative (cas
d'utilisation de la version 1 et étapes suivantes). Nous discutons de la validation des
normes de sécurité des systèmes embarqués C-ITS et des plans de mise en œuvre de
l'infrastructure à clé publique (PKI). Nous présentons des messages déjà
standardisés ainsi qu'une nouvelle proposition de standardisation. Les messages
déjà standardisés se concentrent sur la sécurité des véhicules et l'ef fi cacité de la
circulation, tandis que notre proposition cible la publicité de service.
Je NTRODUCTION
Les systèmes de transport intelligents (STI) font référence à
l'intégration des technologies de l'information et de la communication
avec les infrastructures de transport pour améliorer la sécurité, la
mobilité et la durabilité environnementale au profit de tous les usagers
de la route. Les applications ITS coopératives (C-ITS) sont basées sur les
communications sans fil de véhicule à véhicule (V2V) et de véhicule à
infrastructure (V2I). Sur la base des messages échangés, les
applications C-ITS fourniront d'abord les avertissements de danger
routier et les informations sur la circulation au conducteur, puis
réagiront automatiquement.
Malgré les nombreux avantages potentiels du C-ITS, les communications
sans fil associées soulèvent des problèmes de sécurité et de confidentialité
qui, s'ils ne sont pas résolus, pourraient compromettre leur déploiement.
Pour sécuriser les communications C-ITS, il est généralement admis
d'utiliser la cryptographie asymétrique, ce qui nécessite de mettre en
place une infrastructure à clé publique (PKI) pour la gestion des
informations d'identification de sécurité de la station ITS (ITS–
S). Un problème clé est d'assurer l'interopérabilité des
communications sécurisées pour les différents types de
communications sans fil: Vehicle-2-Vehicle (V2V),
Vehicle-2-Infrastructure (V2I) et Vehicle-2-PKI lorsque la station ITS
doit se connecter au Les entités PKI sont également appelées
autorités de certification (CA) à des fins de gestion de la sécurité.
Un autre problème majeur à prendre en compte est la confidentialité des
utilisateurs [14]. Tout système de gestion des informations d'identification de
sécurité doit envisager un système de protection de la vie privée pour protéger
l'identité des véhicules et des utilisateurs conformément à la législation nationale
et internationale.
Le reste de cet article est organisé comme suit. La section II
présente les activités de normalisation sur la sécurité C-ITS en
mettant l'accent sur le cadre de sécurité ETSI et
progrès de la normalisation. La section III décrit la conception ETSI PKI
et les modèles de données pour les messages et certi fi cats sécurisés.
La section IV décrit la mise en œuvre des services de sécurité pour
divers messages. L'expérimentation et la validation du C-ITS sont
discutées dans la section V. La conclusion est donnée dans la section VI.
II. C-ITS S ÉCURITÉ: S TANDARDITION UNE CTIVITÉS
A. Cadre des normes de sécurité des STI
Afin d'atteindre l'interopérabilité C-ITS, le développement de normes de
sécurité des communications ITS est primordial. À cette fin, des groupes de
travail dédiés au sein des organisations de normalisation traitent des
questions de sécurité et de confidentialité. Par exemple, le groupe de travail
ETSI TC ITS WG5 en Europe [1] et le groupe de travail IEEE 1609.2 en
États-Unis [2].
L'IEEE 1609 DSRC WG a développé une norme pour la spéci fi
cation des «services WAVE de sécurité» permettant des
communications sans fil sécurisées des messages d'application et
de gestion WAVE (IEEE 1609.2 [3]). Dans IEEE 1609.2, le service
d'authenticité et d'intégrité des messages est basé sur des
signatures numériques utilisant l'algorithme de signature
numérique à courbe elliptique (ECDSA). La protection de
confidentialité est basée sur le cryptage symétrique AES (cryptage
authentifié AES-CCM). Un schéma de cryptage asymétrique
utilisant un schéma de cryptage intégré à courbe elliptique (ECIES)
est fourni et est utilisé pour transporter des clés de cryptage
symétriques [3]. La portée de la norme IEEE 1609.2 est de définir
les structures de données de sécurité et en particulier les formats
de messages sécurisés, et le traitement de ces messages sécurisés
dans le système DSRC / WAVE.
En Europe, l'ETSI TC ITS est organisé en cinq groupes de travail:
exigences applicatives, architecture cross layer, réseaux de
transport, médias et sécurité. ETSI TC ITS WG5 traite des aspects
de confidentialité, de protection des données et de sécurité dans
les STI. Trois étapes composent le processus de sécurité de ce
groupe: (i) identifier et cataloguer les risques de sécurité des STI,
(ii) construire des exigences de sécurité et définir une liste de
contre-mesures potentielles (services de sécurité génériques), (iii)
spécifier une architecture et un ensemble normalisé de services et
interfaces qui permettent la mise en œuvre de communications
sans fil sécurisées véhicule-véhicule (V2V) et véhicule-infrastructure
(V2I).
Dans le cadre de l'ETSI ITS Release 1 [4], une réalisation majeure des travaux de
l'ETSI dans ce domaine, a été la conception d'un système de sécurité.
cadre pour C-ITS, y compris une PKI pour la gestion des certi fi cat et matériel sécurisé pour ITS – S. Les exigences et les spécifications
numériques. Cela comprend la publication des documents énumérés techniques sont basées sur TVRA et les services de sécurité
dans le tableau I. recommandés (voir le tableau I).
Le cryptosystème ETSI pour les communications C – ITS est actuellement
TABLEAU I: Normes de sécurité ETSI ITS basé sur IEEE 1609.2 [3]. De récents projets de déploiement national en
Standard Europe ont soulevé des problèmes d'évolutivité et d'évolutivité dans la
Titre Statut
Référence conception: ils nécessitent la capacité d'améliorer les crypto-algorithmes au
Rapport technique d'analyse des menaces,
TR 102 893 v1.1.1 Publié fil du temps dans le système C – ITS, ce qui est un problème majeur dans les
de la vulnérabilité et des risques (TVRA)
TS 102 731 Services et architecture de sécurité Formats v1.1.1 Publié systèmes embarqués en raison de ressources limitées (c.-à-d. Module de
d'en-tête et de certi fi cat de sécurité sécurité matérielle, crypto-accélérateurs).
TS 103097 v1.2.1 Publié

Sécurité des communications ITS

v1.2.1 Sous
TS 102940 architecture et sécurité
approbation
la gestion
v1.1.1 Publié
TS 102 941 Gestion de la confiance et de la confidentialité
sous révision
TS 102 942 Contrôle d'accès v1.1.1 Publié
TS 102 943 Services de confidentialité v1.1.1 Publié

Les normes de sécurité ETSI ITS couvrent les besoins et les objectifs de
sécurité actuels des STI, en fonction de l'état de l'analyse des risques de
l'analyse des risques de menace et de vulnérabilité [5] (TVRA). Une
caractéristique essentielle de ce cadre de sécurité est d'inclure la protection
de la vie privée pour les utilisateurs et les véhicules de systèmes STI
coopératifs, par exemple en utilisant des pseudonymes certi fi cat pour les
communications sécurisées sans fil et en les changeant régulièrement.

TABLEAU II: mise en correspondance des services de sécurité génériques Fig.1: Modèle de confiance ETSI ITS (PKI).
avec l'architecture de sécurité et les services et interfaces normalisés
associés.
A. Conception ETSI ITS PKI
Un service Standard
Catégorie
Service de sécurité
Référence
Le concept de sécurité ETSI utilise des certi fi cats à long terme
Obtenir / supprimer / mettre à jour les TS 102 941 pour l'identification et la responsabilité de l'ITS – S, nommés Certificats
Inscription
informations d'identification d'inscription sous révision d'inscription ( EC) et des certificats anonymes de courte durée pour
Obtenir / Mettre à jour le ticket TS 102 941
Autorisation les communications V2V / V2I, nommés Billets d'autorisation ( AT)
d'autorisation sous révision
Seul Autoriser / Valider ou certi fi cat pseudonyme.
TS 102940
Un message Autorisation sur single Les problèmes de confidentialité sont introduits en raison du contenu des
TS 103097
Signature Un message
messages de sécurité, c'est-à-dire des messages de sensibilisation
Données Crypter / Décrypter un TS 102940
Chiffrement message unique TS 103097 coopérative (CAM) et des messages de notification environnementale
Rejouer Protection contre la relecture basée sur TS 102940 décentralisée (DENM) (voir la section IV), et en raison de l'authentification
protection l'horodatage TS 103097 appliquée aux messages (signature de message). Les certi fi cats
TS 102940
Plausibilité Valider la plausibilité des données cryptographiques permettent le suivi des véhicules ITS. La vie privée des
TS 103097
Sécurité Établir / mettre à jour / supprimer Voir RFC utilisateurs est protégée par un système de pseudonyme, c'est-à-dire en
Les associations l'association de sécurité, envoyer / proposition pour TLS changeant fréquemment les certificats de pseudonyme (AT) utilisés pour
la gestion recevoir un message sécurisé extension [13]
authentifier les messages tels que CAM ou DENM. De ce fait, le suivi des
Intégrité Somme de contrôle Non supporté
Responsabilité- Enregistrer le message entrant véhicules est évité ou, du moins, rendu plus difficile. Pour atteindre cet
Non supporté
ité / sortant objectif de confidentialité, l'ICP doit émettre et distribuer un grand nombre
À distance Activer / désactiver la
Non supporté de tickets d'autorisation (pseudonyme de certi fi cat) à chaque ITS – S. La
la gestion transmission ITS
Signaler un mauvais comportement à l'ITS – Non pris en charge dans
discussion sur d'autres méthodes de repérage telles que l'empreinte radio
Signaler
S, détection et prévention des mauvais Version 1 TS ou le repérage des téléphones portables n'entre pas dans le cadre de cet
Mauvaise conduite
comportements par 102940 et 941
ITS – S article.
Autorité de mauvaise conduite extension future
La conception ETSI considère une structure PKI hiérarchique, avec
l'AC racine (RCA) agissant comme l'ancre de confiance pour un domaine
de confiance C-ITS donné et contrôlant toutes les autorités de
III. S ÉCURITÉ POUR V2V / V2I C OMMUNICATIONS
certification subordonnées (CA) et les entités finales dans sa hiérarchie
ETSI ITS WG5 a développé des exigences et des spécifications techniques (voir Fig. 1). Le système PKI C-ITS peut être constitué d'un certain
pour des communications sécurisées et préservant la confidentialité, des nombre de RCA, qui peuvent coopérer et se certifier mutuellement. Par
formats de messages sécurisés, des certi fi cats, une structure PKI exemple, en Europe, les RCA pourraient être exploités par divers
 pro fi ls des certi fi cats RCA, EA, AA et des entités finales (CE,
AT).
Pour les messages de sécurité, tels que CAM et DENM, chaque
message porte ses propres informations de certi fi cat et de
(une)
signature en raison du traitement sensible au retard des
informations de sécurité côté récepteur. L'omission de certi fi cat
permet de réduire l'utilisation de la bande passante du réseau, au
détriment d'un temps de latence plus élevé pour la vérification des
(b) messages par le récepteur (voir Fig. 2b). A cet effet, ETSI TS 103097
fournit un SignerInfo champ contenant l'identifiant du certi fi cat
Fig. 2: (a) Message signé avec ticket d'autorisation. (b) Message d'autorisation spécifié comme le condensé de certi fi cat 8 octets
signé avec Certi fi cat Digest. avec sha256.
L'ETSI TS 103 097 spéci fi e comment la structure est codée
et doit être traitée par les services de traitement de sécurité
parties prenantes, telles que les gouvernements (UE / nationaux), les
dans l'entité de sécurité ITS – S [7]. Il comprend un
constructeurs automobiles, les fournisseurs de télécommunications, etc.
version du protocole, champs d'en-tête, une champ de charge utile et champs
En raison de la nature de diffusion du CAM et du DENM, la
de remorque. La structure est conçue pour être flexible, de sorte que les
relation de confiance entre les stations ITS doit être évolutive
champs d'en-tête et de fin sont de longueur variable et peuvent contenir
(des centaines de millions de nœuds) et vérifiable
n'importe quel nombre d'instances de chaque champ défini (0, un ou
instantanément. Pour répondre à ces exigences, l'inscription et
plusieurs). Les éléments SecuredMessage sont formatés comme suit:
l'autorisation ITS – S pour différents services sont déléguées à
• Les champs d'en-tête ou de fin doivent commencer par un champ de
des tiers de confiance (TTP), composés de deux types de CA:
longueur spécifiant la longueur totale de l'en-tête ou de la fin en
Autorité d'inscription (EA): Valide qu'un ITS – S peut être
octets.
de confiance. Il délivre un identifiant d'inscription pour l'ITS-S
• Le champ de charge utile ne doit contenir qu'une seule charge utile de
et une preuve de son identité (certificat d'inscription).
message.
Autorité d’autorisation (AA): Un ITS – S peut demander
• Chaque champ de l'en-tête, de la charge utile et de la remorque
services et autorisations spéci fi ques. Ces privilèges sont
doit être précédé, respectivement, d'un HeaderFieldType,
indiqués au moyen de tickets d'autorisation (AT).
PayloadType et TrailerFieldType.
Au sein du réseau C-ITS, l'EA fournit un ITS – S avec un ID
Les champs d'en-tête contiennent des informations utilisées par la
d'inscription et un certificat d'inscription associé (à long terme).
couche de sécurité, telles que des données de plausibilité ( generation_time,
L'AA fournit à l'ITS-S plusieurs pseudonymes et les tickets
expiration, generation_location, request_unrecognized_certi fi cate,
d'autorisation associés (à court terme), à utiliser dans la
its_aid, signer_info, encryption_parameters, receiver_info)
communication V2X.
et peut être étendu davantage (avec des champs inconnus). Itsaid spéci
fi e le pro fi l de sécurité à appliquer et dé fi nit l'utilisation des champs
Élément Valeur La description
d'en-tête, de charge utile et de fin correspondant à ce type de message.
Longueur
SécuriséMessage
protocol_version 0x02 1
header_f ields <var> 0x8091 Longueur: 145 octets = 2
Un seul champ de charge utile est autorisé et ce champ commence par
taper 0x80 signer_info 1
taper 0x02 = ce rtifi ca te 1
le type de charge utile et la longueur des données de charge utile. Le
Type de ce rtifi ca te du signataire = il 141
champ de fin est de longueur variable et contient différents champs de
...

certificat 0x05 s_a id 1

Ça disait 1
fin, par exemple une signature. La figure 3 donne un exemple de
...

charge utile
taper 0x01 = signé 1
données <var> 0x01 Longueur: 1 octet de 1
codage de message sécurisé où le signataire est identifié par son certi
1
fi cat.
[ Les données ] ... charge utile
bande-annonce _ fiel ds <var> 0x43 Longueur: 67 octets = 1
taper 0x01 signature 1
Signature
algorithme 0x01 = ecdsa_nistp256_with_sha256 1
C. Modélisation des rôles et des autorisations dans les certi fi cats ETSI
ecdsasignature
R Afin d'accéder au réseau ITS et d'utiliser pleinement les applications,
taper 0x00 = x_coordinate_only 1
X ... 32 services et capacités ITS disponibles, une station ITS doit obtenir des
s ... 32
Taille totale: 219 octets informations d'identification spécifiques auprès de l'autorité
d'autorisation. Ces informations d'identification, sous la forme de
Fig. 3: Exemple d'ETSI SecuredMessage (signé). certificats signés cryptographiquement, sont utilisées pour garantir à
tout ITS – S récepteur que la station émettrice est fiable et dispose des
autorisations nécessaires pour envoyer les informations spécifiques au
B. Spécification du format de message sécurisé ETSI service. Les utilisateurs du système ITS peuvent avoir différents rôles et
ETSI TS 103 097 [6] spéci fi e les structures de données pour les différents niveaux d'autorisation (par exemple, véhicule personnel,
messages sécurisés. La figure 2a représente la structure générale véhicules d'urgence, RSU, unités fixes ou mobiles de travaux routiers
d'une enveloppe de sécurité pour les messages signés. Le ...).
document spéci fi e des pro fi ls de sécurité pour CAM, DENM et un Les certificats d'autorisation ne sont délivrés à un ITS – S
pro fi l générique. Le format du certi fi cat est spécifié et comprend qu'après qu'une procédure complète a été suivie afin de
 Fournisseur ITS-S Utilisateur ITS-S

Serveur bord de la route (véhicule)

registre de service

boucle

chaque 1Herz construire SAM

signer SAM avec AT (its-aid, ssp)

envoyer un SAM signé (ServiceInfo, ChannelInfo, RA )

vérifier la signature

(une) récupérer la clé de chiffrement AT

récupérer le contact ProviderServer

créer une adresse ipv6 à partir des informations du routeur (RA)

paquet ipv6 (@user, @ProviderServer, REQ_1)

Si aucune confidentialité de
Démarrer la session du minuteur
l'utilisateur, le message est uniquement

signé (chiffrement
paquet ipv6 (@user, @PS, REQ_1)
optionnel)
paquet ipv6 (@user, @ProviderServer, REQ_2)

paquet ipv6 (@user, @PS, REQ_2)

RES
RES

recevoir ACK ou fin de la minuterie

ACK
(b)

Fig. 4: Structure d'un message CAM (a) et DENM (b) signé. Fig. 5: Flux de messages pour la publicité de service et le cas
d'utilisation du service.

protéger son identité et éviter toute utilisation abusive des services ITS
et des capacités du réseau (initialisation / enregistrement, inscription et
autorisation).
Dans le cadre de sécurité ETSI, le certi fi cat d'autorisation
indique les permissions du détenteur du certi fi cat, c'est-à-dire
quelles déclarations le titulaire est autorisé à faire ou quels
privilèges il est autorisé à affirmer dans un message signé diffusé
sur le canal de communication ITS G5.
Dans l'architecture ETSI, l'ITS-Application Identi fi er (ITSAID)
permet d'identifier un message, un service ou une application Fig. 6: Exemple de requête signée et cryptée.
donné. Le champ ITS-AID dans le certi fi cat ITS – S (AT) indique les
autorisations globales accordées au véhicule: par exemple, il y a un
(CAM, DENM et pro fi l générique). Le profil de sécurité ETSI TS 103
ITS-AID qui indique que l'expéditeur est autorisé à envoyer des
097 spéci fi e quels champs doivent être inclus (et non inclus) dans
CAM, et un autre pour indiquer que l'expéditeur a le droit
un en-tête de sécurité. Pour certains champs d'en-tête, les valeurs
d'envoyer des DENM. Les autorisations spécifiques au service (SSP)
à utiliser sont spéci fi ées dans la norme de message (par exemple,
sont un champ qui indique des ensembles spécifiques
CAM, DENM): l'ITS-AID est spéci fi é dans ETSI TS 102 965 et
d'autorisations pour un message, un service ou une application
l'utilisation SSP est spéci fi ée dans [8] et [9].
(ITS-AID) donné. Ceci est utilisé pour élever les privilèges de
La section IV-A présente la structure des messages sécurisés
l'expéditeur dans cette application (ou fonction de génération de
CAM et DENM déjà normalisés, tandis que la section IV-B
message). Par exemple, il peut y avoir une valeur SSP associée à
discute de notre proposition: le message d'annonce de service
l'ITS-AID pour CAM qui indique que l'expéditeur est autorisé à
(SAM). SAM est un message de communication d'infrastructure
envoyer des CAM pour un rôle de véhicule spécifique (par exemple,
à véhicule (I2V) actuellement en cours de normalisation avec
véhicule d'urgence, transport public ...).
d'autres messages I2V tels que SPATEM, MAPEM, IVIM, etc.
Les autorisations accordées à une station ITS sont indiquées
spéci fi és dans [20]. Ces messages I2V utilisent le profil de
dans le certi fi cat par une paire d'attributs: ITS-AID et SSP. Le
sécurité générique.
format de certi fi cat TS 103097 permet à un certi fi cat de contenir
plusieurs ( SON - AID, SSP) paires.
A. Messages normalisés
IV. S ÉCURITÉ S ERVICES je MÉLÉMENTATION EN R ELEASE 1 U SE Sur la base des cas d'utilisation spéci fi és par le Car2Car Communication
C ASES ET F UTURE UNE PPLICATIONS Consortium (C2C-CC) pour Day1 [12], deux types de messages principaux ont
Cette section détaille le format du message sécurisé utilisé par été spéci fi és pour fournir des informations hautement dynamiques pour
diverses applications C – ITS. Les formats d'un SécuriséMessage est les applications de sécurité routière. Ils peuvent également être utilisés
dé fi nie dans ETSI TS 103097 pour différents pro fi ls comme données de sonde de véhicule pour la gestion du trafic
comme dans le projet pilote CORRIDOR & SCOOP @ F. Ces types de
messages sont:
Message de sensibilisation coopérative (CAM): permet d'élargir
diffuser périodiquement des informations aux stations voisines
(communication en un seul saut). CAM contient une identité de
pseudonyme (stationID), un emplacement basé sur GNSS et un
horodatage et des informations dynamiques du véhicule (telles que la
vitesse, le cap, etc.). Pour les véhicules, les CAM sont diffusés en
permanence à une fréquence réglable entre 1 et 10 Hz en utilisant le
canal CCH et le protocole IEEE 802.11p. Les véhicules à rôle spécial
peuvent utiliser des conteneurs optionnels pour fournir des
informations de situation, par exemple, un véhicule d'urgence utilisant
sa sirène ou sa barre lumineuse.
Décentralisé Environnement Noti fi cation Un message
(DENM): est transmis lorsqu'un véhicule détecte un événement (détection des
dangers de la route). Un DENM contient un identifiant de station (pseudonyme),
un type d'événement, une heure de génération, une position, une heure de
validité, une zone de pertinence et une direction de trafic. Les DENM sont diffusés
par l'ITS-S d'origine à une fréquence donnée (par exemple à 10 Hz) et pendant une
durée donnée ou jusqu'à la fin de l'événement détecté. Les DENM sont
géo-diffusés en mode multi-sauts en utilisant les informations de localisation pour
transférer les paquets.
Les normes CAM et DENM ont été spéci fi ées par l'ETSI et poussées
comme normes européennes (voir [8], [9]). Étant donné que CAM et
DENM fournissent des informations de sécurité urgentes aux véhicules
à proximité, la confidentialité des données n'est pas requise. En
revanche, l'origine de l'expéditeur, l'intégrité des données et les
informations de géo-routage doivent être protégées et une signature
numérique est appliquée. TS 103 097 dé fi nit les pro fi ls de sécurité
des CAM et des DENM. La figure 4a et la figure 4b présentent
respectivement la structure d'un CAM signé et d'un DENM signé.
Fig. 7: Structure d'un message SAM signé.
Message d'annonce de service (SAM)
Nous contribuons à l'activité de normalisation ETSI avec une
proposition de standardisation du message d'annonce de service
(SAM). Les messages SAM sont utilisés par les fournisseurs de
services pour informer les stations ITS des services locaux
disponibles ou des services accessibles sur un serveur distant. La
figure 7 donne un exemple d'un message SAM signé. Le message
est actuellement en cours de dé fi nition par ETSI [15] et en cours
d'harmonisation avec WSA WAVE Service Announcement (IEEE
1609,3 [16]). Les SAM / WSA ne contiennent pas eux-mêmes
d'informations sur les applications, mais ils fournissent des
informations sur les services proposés ( ServiceInfo) et les
coordonnées du fournisseur de services local ou distant ( ChannelInfo,
CommunicationInfo, etc.) permettant à l'utilisateur de décider de
se connecter ou non.
Les messages SAM sont diffusés (un saut) sous forme de messages non
chiffrés et généralement envoyés plusieurs fois par seconde.
Afin de protéger l'intégrité et l'authenticité des messages, les
fournisseurs ITS – S doivent signer les messages SAM à l'aide d'un ticket
d'autorisation avec des autorisations spéci fi ques, c'est-à-dire avec un
ITS-AID dédié et un SSP vides. De cette façon, les ITS – S sont protégés
contre les attaques telles que les fournisseurs de services faux ou
malveillants et les usurpations d'identité de serveur Internet.
Comme la nature du service est diffusée à tous les récepteurs possibles et que
l'expéditeur est une RSU statique ou un véhicule mobile qui accepte de jouer un
rôle distinctif (par exemple, véhicule leader dans un peloton), aucune exigence de
confidentialité ne s'applique.
Dans de nombreux cas, l'ITS-S qui répond est associé à un véhicule de
l'utilisateur final avec une forte attente en matière de respect de la vie
privée. Le diagramme de la figure 5 donne un exemple de la manière dont
une communication monodiffusion sécurisée peut être établie pour
l'exécution du service sélectionné.
Dans l'exemple de la figure 5, si la confidentialité de l'utilisateur est
requise, nous supposons que l'unité de fournisseur ITS – S signe avec
un AT comprenant deux clés: une clé de vérification et une clé de
cryptage. Une clé symétrique temporaire (AES-CCM 128 bits) est créée
par l'utilisateur et est transportée avec la demande REQ en utilisant un
schéma de cryptage ECIES asymétrique (c'est-à-dire la clé de cryptage
de l'unité fournisseur).
Cette méthode de cryptage hybride permet l'intégrité et le cryptage
du volume de données moyen et grand en utilisant la clé AES-CCM (voir
[23] pour les détails de la méthode AES-CCM). Par exemple, si
l'utilisateur ITS – S souhaite envoyer une REQ supérieure à 1 000 octets,
il peut être nécessaire de fragmenter / réassembler le message au
niveau de l'application. La fragmentation permet la limitation de la
taille des paquets et la gestion de la congestion des canaux ITS-G5.
Dans ITS G5, la MTU (unité de transmission maximale) autorisée pour
les paquets GN est MTU_GN = 1492 octets - en-têtes GN & BTP (voir
[17]) et pour les paquets IPv6 est MTU_IPv6 = 1.500 - en-têtes LLC, SNAP
et IPv6 (voir [18] ]). Pour un canal de service G5 (SCH) en raison du
contrôle d'encombrement, la taille d'une trame peut être limitée à 750
octets à 6 Mbit / s (voir [19]). Ainsi, l'ITS – S doit fragmenter le message
REQ en plusieurs parties chiffrées (voir la figure 5). Notez que puisque
deux fragments ne peuvent pas partager la même paire clé / nonce
[23], une nouvelle clé ou un nouveau nonce doit être utilisé pour
chaque message. La nouvelle paire clé / nonce doit être incluse dans
chaque fragment, ajoutant une surcharge non négligeable sur la taille
du message. Nous travaillons actuellement à des solutions alternatives
pour réduire ces frais généraux.
En outre, le fournisseur de services (RSU) peut décider d'authentifier
l'utilisateur ITS – S qui répond pour contrôler l'accès à ses propres
ressources et à son réseau d'infrastructure: en utilisant la norme de sécurité
ETSI, l'utilisateur ITS – S qui répond doit envoyer un message chiffré et signé
en utilisant les
SécuriséMessage structure de données (voir la clause ETSI TS 103097
5.1) qui porte une charge utile de type signed_and_encrypted
(voir Fig.6).
V. C-ITS S ÉCURITÉ: E XPERIMENTATIONS ET V ALIDATIONS
La dé fi nition de normes pour la conception et la mise en œuvre du
cadre de sécurité C-ITS est nécessaire mais pas suf fi sante. Des
expérimentations, des tests et la validation des normes ETSI sont
nécessaires [24].
Récemment, l'ETSI a développé des tests de sécurité pour la
norme de base (TS 103097) au sein de la STF 481 et a développé la
plate-forme de conformité de test comprenant 64 cas de test qui
seront encore étendus avec plus d'erreurs et de cas de test
d'exception. Lors du 4e test ITS CMS ETSI Plug qui s'est tenu à
Helmond, du 17 au 27 mars 2015, les tests de conformité de la
norme de base de sécurité ETSI (TS 103097) ont été effectués à
l'aide de l'outil de test de conformité ETSI. Le test d'interopérabilité
de diverses implémentations en configuration face-à-face a été
réalisé [21].
De plus, un travail continu vers le développement de STI standardisés a été
réalisé dans le cadre de projets de tests opérationnels sur le terrain (FOT) en
Europe, tels que DRIVE C2X, Score @ F et PRESERVE [10]. De nouveaux projets
pilotes, comme SCOOP @ F en France, se concentrent sur les tests et le
déploiement à grande échelle. Voir [25] pour une enquête sur les architectures et
les projets C-ITS.
Dans le projet ISE de SystemX IRT [11], l'objectif principal est la
conception et la mise en œuvre d'une PKI C-ITS évolutive et fl exible, car
nous prévoyons un déploiement progressif dans le temps (avec plusieurs
domaines de confiance contrôlés par une autorité de certification racine et
plusieurs autorités de certification dans un domaine de confiance). La mise
en œuvre est entièrement conforme aux normes ETSI et une évaluation
approfondie des performances est prévue, basée sur un environnement de
test en laboratoire comprenant des tests de pénétration de sécurité et basée
sur l'expérimentation et l'analyse de test résultant de l' exploitation de la
flotte de véhicules SCOOP @ F et des RSU. Nous prévoyons également de
réaliser des tests d'évolutivité basés sur le déploiement à grande échelle de
la PKI géo-répliquée.
VI. C ONCLUSION
Les normes de base ETSI Release 1 sont maintenant
disponibles ou en phase de rédaction finale, permettant le
déploiement des premières applications de base pour la
conduite coopérative et l'ef fi cacité de la circulation, soutenues
par des messages standardisés sécurisés tels que CAM, DENM
et SAM (Annonces de services aux applications ou utilisateurs
ITS-S ) et les messages I2V tels que SPATEM, MAPEM et IVIM
[20]. Les groupes de parties prenantes ont développé une
feuille de route de déploiement (voir la feuille de route et les
directives C2C-CC pour les applications Day1 [12]). Aujourd'hui,
la mise en œuvre de l'ICP délivrant des certi fi cats de sécurité
aux entités C-ITS de confiance est essentielle pour soutenir le
déploiement initial des STI en Europe (voir [22] pour une
description de l'organisation et de la structure de l'ICP C2C-CC).
Pour un système de communication ITS d'une telle envergure,
avec plusieurs centaines de millions d'ITS – S,
études de recommandations juridiques et politiques en Europe et dans
le cadre d'initiatives d'harmonisation plus larges entre différentes
régions (UE, États-Unis, Japon, Australie ...).
Le cadre de sécurité ETSI devrait être étendu en fonction des
exigences de l'industrie, par exemple, pour prendre en charge les
certi fi cats et les extensions PKI, la crypto-agilité, les exigences du
système de sécurité embarqué et la gestion des assurances
(schéma d'évaluation). En outre, la version 2 du cadre de sécurité
ETSI devrait être totalement interopérable avec les stations ITS
opérationnelles déjà déployées sur le terrain (rétrocompatibilité).
UNE REMERCIEMENTS
Ces travaux de recherche ont été menés dans le cadre de
l'Institut de Recherche Technologique SystemX.
R ÉFÉRENCES
[1] http://www.etsi.org/technologies-clusters/technologies/intelligenttransport/cooperative-its
[2] https://standards.ieee.org/develop/wg/1609_WG.html
[3] IEEE 1609.2-2016, norme IEEE pour l'accès sans fil dans les environnements
véhiculaires - Services de sécurité pour les applications et les messages de
gestion.
[4] ETSI TR 101 067: «Systèmes de transport intelligents (STI); ITS coopératif
(C-ITS); Version 1 ».
[5] ETSI TR 102 893: «Systèmes de transport intelligents (ITS); Sécurité; Analyse des
menaces, de la vulnérabilité et des risques (TVRA) ».
[6] ETSI TS 103 097: «Systèmes de transport intelligents (ITS); Sécurité; En-tête de
sécurité et formats de certi fi cat ».
[7] ETSI TS 102 940: «Systèmes de transport intelligents (ITS); Sécurité;
Architecture de sécurité des communications ITS et gestion de la sécurité ».
[8] ETSI EN 102 637-2: «Systèmes de transport intelligents (STI); Communications
véhiculaires; Ensemble d'applications de base; Partie 2: Spéci fi cation du
service de base de sensibilisation coopérative ».
[9] ETSI EN 102 637-3: «Systèmes de transport intelligents (STI); Communications
véhiculaires; Ensemble d'applications de base; Partie 3: Spéci fi cations du
service de base de noti fi cation environnementale décentralisée ». [10] Projet
PRESERVE, https://www.preserve-project.eu/
[11] Projet ISE, http://www.irt-systemx.fr/project/ise/?lang=en
[12] Car2Car Communication Consortium, https://www.car-2-car.org/ [13]
Authentification Transport Layer Security (TLS) à l'aide de l'ETSI TS 103097
et certi fi cat IEEE 1609.2, draft-v2-tls-cert-ETSI-IEEE.
[14] G. Calandriello, P. Papadimitratos, A. Lloy et J.-P. Hubaux, «ef fi cace
et authentification pseudonyme robuste dans VANET », ACM VANET
2007.
[15] ETSI TS 102 890-2: «Systèmes de transport intelligents (STI); Couche des installations
une fonction; Spéci fi cation des annonces de services ».
[16] IEEE 1609.3 Rev 3, norme IEEE pour l'accès sans fil dans les véhicules
(WAVE), Networking Services, 17 mars 2015.
[17] ETSI EN 302 636-4-1: Systèmes de transport intelligents (ITS); Véhicule
les communications; GeoNetworking; Partie 4: Adressage et retransmission
géographiques pour les communications point à point et point à multipoint;
Sous-partie 1: Fonctionnalité indépendante des médias.
[18] IETF draft-petrescu-ipv6-over-80211p-02
[19] ETSI TS 102 687: Systèmes de transport intelligents (ITS); Décentralisé
Mécanismes de contrôle de la congestion pour les systèmes de transport intelligents
fonctionnant dans la gamme 5 GHz; Partie de couche d'accès.
[20] Projet ETSI TS 103 301: Systèmes de transport intelligents (STI); véhicules
Les communications; Ensemble d'applications de base; Protocoles de la couche Installations
et exigences de communication pour les messages I2V.
[21] Résumé des résultats du 4e Plugetst de services de mobilité coopérative ITS,
Sebastian Mueller, ITS Workshop, Helmond, 27 mars 2015.
[22] N. Bißmeyer, H. Stübing, E. Schoch, S. Götz, JP. Stotz et B. Lonc. UNE
infrastructure à clé publique générique pour sécuriser la communication Car-to-X
Dans ITS World Congress, 2012.
[23] "C-ITS Security: Standards and experimentations" publié dans
Journées Nationales des Communications dans les Transports.
[24] R. Moalla, H. Labiod et B. Lonc «C-ITS Security: Standards and
expérimentations », JNCT 2013.
[25] A. Boudguiga, A. Kaiser et P. Cincilla «Cooperative-ITS Architecture
and Security Challenges: a Survey », 22e Congrès mondial sur les STI, 2015.