blog
22 juillet 2024
Introduction
Dans cet article, les acronymes utilisés se rapportent aux acronymes des normes 3GPP LTE.
Selon les normes 3GPP, pour réduire l’activité d’une cellule, il existe deux mécanismes :
- L’objectif du mécanisme de contrôle de sélection et de re-sélection de cellules est d’interdire l’accès de la cellule aux UE. La cellule est à l’état Barré (barred) ou Réservé (Reserved).
- Le mécanisme de contrôle d’accès a pour objectif de contrôler la charge d’une cellule afin de réduire la congestion. Le mécanisme s’applique à des classes d’UE. La classe d’UE est inscrite sur l’application USIM au moment de l’inscription [25.304]. L’accès à la cellule est dit restreint.
Reprenons les définitions de 3GPP sur les états de la cellule [TS 36.300]
- Barred Cell: Un UE ne peut pas camper sur une cellule barrée
- Reserved Cell: Un UE ne peut camper sur une cellule réservée que s’il satisfait à la condition d’autorisation.
- Restricted Cell: Un UE peut camper sur une cellule restreinte, mais la demande d’accès est conditionnée à la classe de l’UE et au service demandé.
(suite…)
30 janvier 2021
Introduction
Selon l’étude de marché menée par Statista en 2018 [1], plus de 75 milliards d’objets seront connectés à Internet en 2025, soit deux fois plus qu’en 2021 (35 milliards d’objets connectés).
Un grand nombre d’objets seront connectés via un réseau bas débit et faible coût, comme LoRaWAN, SIGFOX, ou à travers les réseaux cellulaires (LTE-M/NB-IoT).
En 2009, Christophe Fortet et Ludovic Le Moan ont créé la société SIGFOX pour le marché M2M. Dans le secteur des objets connectés, SIGFOX est le premier à s’être positionné comme Opérateur IoT en déployant son propre réseau sur plusieurs continents (déploiement de l’accès radio-électrique et du cœur de réseau).
(suite…)
26 avril 2020
Avec l’arrivée de la 5G-NSA en juillet 2020, les opérateurs vont être amenés à déployer des stations de base 5G (en-gNB) dans la bande 3.4 à 3.6 GHz avec comme particularité un mode de fonctionnement en TDD (Time Division Multiplex).
La méthode de multiplexage TDD consiste à répartir la bande de fréquence tantôt en émission et tantôt en réception. Ainsi, la même bande de fréquence est utilisée dans les deux sens de transmission ce qui est un atout pour la Massive MIMO.
La Massive MIMO est une extension du FD-MIMO, cela permet d’augmenter le nombre de chaîne radiofréquences entre l’élément antennaire et l’entité radioélectrique RRU/RRH.
Les avantages sont nombreux :
- augmentation de la capacité de la station de base ;
- augmentation du débit utilisateur et amélioration du ressenti de l’utilisateur ;
- gestion plus fine de faisceau et adaptation RF du faisceau (Beamforming).
Nous allons dans cet article expliquer le fonctionnement du Massive MIMO en détaillant la composition d’une antenne. (suite…)
21 janvier 2020
SIP est le protocole de signalisation mis en œuvre dans les solutions VoIP et multimédia aussi bien dans le cadre des réseaux de fixes et de mobiles des opérateurs publics que dans le cadre des systèmes de téléphonie des entreprises et centre d’appels.
Dans le domaine ferroviaire, le réseau de fixes FTS (Fixed Terminal Subsystem) met déjà en œuvre les solutions SIP/VoIP alors que le réseau de mobiles GSM-R utilise encore la commutation de circuits.
L’ETSI ayant en charge les normes relatives au réseau de téléphonie pour le ferroviaire GSM-R (GSM™ for railways), a publié la norme technique ETSI TS 103 389 qui définit le profil SIP à l’interface entre les réseaux de mobiles GSM-R et de fixes FTS.
A l’occasion de la publication de la dernière édition (12/2019) de la norme ETSI TS 103 389, nous avons le plaisir de vous proposer un mémento sur cette norme, téléchargeable ici.
N’hésitez pas à nous contacter pour toute suggestion d’amélioration ou de corrections, à travers notre formulaire de contact.
Note: la norme ETSI TS 103 389 est présentée lors de l’animation de notre formation SIP : Etude et mise en œuvre auprès de participants travaillant dans le domaine de la téléphonie ferroviaire.
4 septembre 2019
A l’heure où la 5G est le sujet actuel dans le monde des réseaux mobiles, il nous semblait intéressant de rappeler qu’il n’existe pas une seule version 5G mais bien plusieurs et de revenir sur les différentes releases 3GPP de la 4G à la 5G.
L’ère des télécommunications cellulaires et numériques a commencé dans les années 1990 avec les réseaux de mobiles de deuxième génération (2G), basés sur le mode d’accès multiple par répartition temporelle TDMA (Time-Division Multiple Access).
Dans les années 2000, les réseaux de troisième génération (3G) se sont développés sur le principe de l’accès multiple par répartition de code à large bande WCDMA (Wideband Code-Division Multiple Access). Bien que la troisième génération ait dominé le marché grâce à l’augmentation du débit pour la transmission de données, elle n’a jamais totalement remplacé la deuxième génération.
Le début des années 2010 voit le démarrage des réseaux de quatrième génération (4G) utilisant l’accès multiple par répartition de fréquences orthogonales OFDMA (Orthogonal Frequency Division Multiple Access) pour la liaison descendante et de l’accès multiple par répartition de fréquence sur une seule porteuse SC-FDMA (Single- Carrier Frequency-Division Multiple Access) pour la liaison montante.
Le développement des réseaux 4G s’est déroulé en trois phases identifiées par les versions du standard de l’organisme de normalisation 3GPP (3rd Generation Partnership
Project) :
- les versions 8 et 9 sont la base du standard LTE (Long Term Evolution) ;
- les versions 10, 11 et 12 sont la base du standard LTE-Advanced ;
- les versions 13 et 14 sont la base du standard LTE-Advanced Pro.
L’organisme de normalisation 3GPP a défini des modèles de service correspondant à des cas d’utilisation et d’exigences spécifiques :
- le service MBB (Mobile Broadband) correspond aux applications et services qui nécessitent une connexion toujours plus rapide, pour permettre par exemple de visionner 2 LTE-Advanced Pro des vidéos en ultra haute définition ou d’utiliser des applications de réalité virtuelle ou augmentée ;
- le service LLC (Low Latency Communication) regroupe toutes les applications nécessitant une réactivité extrêmement importante ainsi qu’une fiabilité du service de
transmission des données, comme la sécurité civile pour des missions critiques ;
- le service MTC (Machine Type Communication) regroupe principalement les usages liés à l’Internet des objets. Ces services ne requièrent pas de débits très importants, mais nécessitent une couverture plus étendue ainsi qu’une consommation énergétique plus faible.
(suite…)
30 avril 2019
Les évolutions technologiques récentes vont bouleverser notre mode de consommation et apporter des changements profonds dans les domaines de la santé, de la logistique, le transport, l’énergie, l’agriculture, …
Si le déploiement de l’IoT (Internet of Things) destiné à collecter un ensemble d’informations constitue la première brique de cette évolution, la plus-value de cette transversalité numérique ne peut être obtenue qu’en garantissant la sécurisation des données collectées et le traitement efficace de ces données.
En cela, la technologie Blockchain s’insère dans l’écosystème de l’IoT en apportant un stockage des données, en assurant le transport sécurisé des données échangées et en permettant la traçabilité des données.
Quant aux traitements des données, l’intelligence artificielle (IA) permet de les valoriser et de les traduire en informations exploitables facilitant ainsi l’analyse décisionnelle des systèmes complexes. De surcroit, les méthodes d’apprentissages autonomes (Machine Learning) permettent également de classifier les données et d’apporter des outils de prédictions des pannes.
Les applications IA pourraient être mise en œuvre sur des lames de serveurs au plus proches des données collectées, formant ainsi un data-center de petite taille (MEC : Mobile Edge Computing).
Ainsi, les secteurs de la santé (capteurs et IA pour détecter l’évolution des maladies), du transport (véhicules autonomes), des chaînes d’approvisionnement (réparation des chaînes de production avant la cassure des pièces usées, l’approvisionnement en flux tendus), de l’énergie (délestages des sites industriels en assurant un transport de l’énergie au plus proche) seront impactés par la complémentarité de ces technologies disruptives.
Dans ces écosystèmes de plus en plus complexes, la donnée reste l’élément fondamental et le premier maillon d’une nouvelle ère économique. Les cabinets d’analystes estiment une évolution constante du marché des capteurs de l’IoT pour atteindre une centaine de milliards de dollars d’ici 2023 et une croissance du taux actuariel (CAGR – Compound annual growth rate) de 13%.
SigFox est le premier opérateur à s’être positionné sur le marché de la transmission sans fil des données issues des capteurs en déployant un réseau de transmission longue portées à basse consommation (LPWAN : LoW Power WAN). Ce réseau LPWAN répond à la demande des compteurs intelligents (smart-meters, compteur d’eau, compteur de gaz), à la gestion des villes (smart-city).
Aujourd’hui, l’opérateur Télécom SigFox est concurrencé par l’opérateur QoWiSio, l’opérateur Américain Ingénu, et l’alliance LoRaWAN avec le déploiement de LoRa par les opérateurs télécoms historiques.
Le réseau cellulaire 4G se positionne également sur ce secteur en étendant ses fonctionnalités pour répondre à l’émergence du marché de l’IoT . Ce réseau dédié aux communications Machine à Machine (MTC – Machine Type Communication) est destiné à devenir le premier réseau cellulaire LPWAN (Low Power WAN). Le premier avantage de cette solution est de pouvoir rapidement apporter une couverture mondiale avec optionnellement une qualité de service.
L’IoT cellulaire (par son réseau d’accès NB-IoT, LTE-M et prochainement 5G NR) devrait connaître la plus forte croissance avec en point de mire, entre 10 000 et 100 000 objets connectés sous la couverture d’une seule station de base.
Le réseau 5G quant à lui va permettre d’apporter de nouvelles solutions pour les communications M2M à temps réel (missions critiques URLLC : Ultra Reliable Low Latency Communication) pour répondre au besoin du secteur de l’automobile et de l’industrie (IIoT – Industrial IoT).
Dans cet article, nous allons présenter à la fois l’évolution de l’architecture du réseau 4G et le déploiement de l’accès radioélectrique LTE-M pour répondre aux besoins en communication des objets connectés.
(suite…)
24 mars 2016
Selon Jeremy Rifkin, la 3ème révolution industrielle est en marche et s’appuie sur l’Internet des objets afin que des centaines de milliards d’objets communiquent en temps réel vers des plateformes de données : de la gestion des bâtiments (smart-building), à celle d’une ville entière (smart-city), de l’énergie (smart-grid) à l’agriculture, du véhicule, aux objets du quotidien, … Toutes nos habitudes seront bousculées par l’arrivée massive de ces objets.
Quels sont les secteurs actuellement visés ? Quels sont les revenus attendus ? Quel est le business model pour les nouveaux opérateurs entrants ? Comment les opérateurs vont-ils pouvoir transporter cette masse d’information du capteur ou du smart-meter aux applications ? Comment assurer l’hétérogénéité des solutions existantes ? Comment 3GPP à travers les réseaux 4,5G et 5G répond-il à de tels besoins et à l’émergence de l’Internet Tactile ?
Afin de répondre à ces questions, NEXCOM Systems propose une nouvelle formation Les réseaux pour le M2M et l’IoT faisant un état de l’art des technologies émergentes de l’IoT et en abordant les solutions techniques adoptées dans les réseaux des Telcos pour répondre à de tels défis.
10 mars 2015
Virtualisation des capacités et cloud computing privé conduisent les entreprises à mettre en place leurs propres data centers afin de disposer de la flexibilité indispensable aux évolutions de leur activité, tout en mutualisant les coûts.
Cependant la conception d’un data center se doit d’être réfléchie, notamment dans le contexte économique actuel : quel est l’espace nécessaire, comment optimiser la consommation d’énergie quand les serveurs blades deviennent la norme, quelle architecture réseau, quels types de protection contre les risques d’attaques extérieures… sont autant de questions à se poser pour concevoir une solution répondant aux besoins.
Afin d’accompagner ses clients dans la conception et la mise en oeuvre de data centers performants et rentables, NEXCOM Systems propose de nouvelles formations dans le domaine de l’urbanisation des data centers, ainsi que dans celui des SDN (Software Defined Networks) et de la sécurité, technologies critiques pour apporter la flexibilité et l’efficacité requises.
1 avril 2014
Le 18 mars 2014, l’ETSI (European Telecommunications Standards Institute) et l’ONF (Open Networking Foundation) ont annoncé un accord pour favoriser le développement des normes NFV (Network Functions Virtualization) en s’appuyant sur le SDN (Software-Defined Networking).
L’infrastructure technique définie dans l’architecture NFV s’appuiera sur les travaux réalisés par l’ONF à travers la normalisation de SDN et du protocole OpenFlow (protocole de configuration et de contrôle des switches).
L’ONF a également publié une présentation sur la manière dont les opérateurs vont pouvoir combiner NFV et SDN pour atteindre les objectifs communs des deux technologies (réduction des coûts, flexibilité, évolutivité, …).
Cette présentation est disponible ici.
Pour poursuivre la lecture, vous trouverez également les détails de cette annonce sur les sites de l’ONF (ici) et de l’ETSI (ici).
20 février 2014
Avec le déploiement de réseaux 4G/LTE et la démocratisation de terminaux compatibles, les solutions de voix sur LTE (Voice over LTE ou VoLTE) se précisent. Réseau de données par excellence, la LTE ne permet pas de passer des appels « voix », à l’exception de l’usage de la voix sur IP (VoIP). Différentes approches ont été envisagées par les opérateurs télécom.
André PEREZ, consultant et formateur LTE et IMS pour NEXCOM Systems aborde ces différentes approches (CS FallBack, SRVCC, …), ainsi que les impacts et interactions avec les infrastructures existantes (IMS) dans un article très détaillé :
Le terme LTE (Long Term Evolution) est utilisé pour désigner les réseaux de mobiles 4G. En fait, il conviendrait de nommer ces réseaux sous le vocable d’EPS (Evolved Packet Service), le terme LTE étant plutôt réservé pour dénommer l’interface radioélectrique entre le réseau 4G et le mobile.
Le service téléphonique est rempli à partir de deux fonctions de base : le transport de la voix et le traitement de la signalisation téléphonique. Le terme Voix sur LTE ou VoLTE (Voice over LTE) est le terme consacré pour désigner le transport de la voix sur IP assuré par le réseau EPS, dans le cadre de la fourniture du service téléphonique à travers une plate-forme IMS.
Lire la suite de l’article VoLTE… (PDF, 370ko)
NEXCOM Systems propose bien évidemment de nombreuses formations sur la LTE, la LTE-Advanced et l’IMS, couvrant les fondamentaux aux concepts plus poussés (interactions avec l’IMS, VoLTE, …). N’hésitez pas à nous contacter pour planifier votre future formation ou obtenir davantage d’informations !
20 janvier 2014
Les mécanismes permettant de réaliser de la voix sur LTE (VoLTE ou Voice over LTE) vont devenir une réalité avec le déploiement des réseaux 4G/LTE ainsi que la démocratisation de terminaux compatibles. Réseau de données par excellence, la LTE n’est pas en mesure d’acheminer des communications voix en mode circuit et nécessite dans certains cas de se reposer sur des mécanismes de handover sur réseau 2G/3G. Problématique complexe de ce nouveau réseau mobile, la VoLTE représente un pan entier de cette technologie.
Formateur LTE/IMS pour NEXCOM Systems depuis de nombreuses années, André Pérez publie également régulièrement des ressources sur diverses technologies (IPv6, LTE, …). Le sujet de la voix sur LTE est notamment abordé dans son dernier livre, La voix sur LTE : réseau 4G et architecture IMS. Il y détaille les différents mécanismes utilisés pour réaliser des appels téléphoniques depuis des terminaux LTE (par exemple CS FallBack) et apporte ainsi une vision globale du problème et des solutions disponibles aujourd’hui, tout en prenant en considération les impacts et interactions avec l’infrastructure IMS. Publié aux éditions Hermès, ce livre est disponible au travers de la librairie Lavoisier.
NEXCOM Systems propose de nombreuses formations sur la LTE : fondamentaux, concepts avancés, interaction avec l’IMS, VoLTE, … N’hésitez pas à nous contacter pour davantage d’informations !
28 mai 2013
WebRTC (Web for Real Time Communication) est une technologie qui évolue très rapidement. Après les premiers succès d’interopérabilité entre navigateurs Web, les deux clients majeurs (Google Chrome et Mozilla Firefox) sont sur le point de proposer tous deux le framework dans la version courante (stable) de leur navigateur. Cela marque une étape majeure dans le développement de la technologie : elle est désormais suffisamment stabilisée pour être rendue disponible à un plus large public.
(suite…)
30 avril 2013
Le Web a 20 ans !
Photo par D Sharon Pruitt
Il y a 20 ans, Tim Berners-Lee et le CERN libérait le « World Wide Web ». D’un simple serveur, une toile complète s’est formée à travers le monde et est une des technologies les plus utilisées encore aujourd’hui.
Longue vie au Web et à ses descendants (dont le très récent et très à la mode WebRTC) !
30 avril 2013
IPv4 (Internet Protocol version 4) demeure à ce jour le protocole le plus utilisé dans ce grand réseau mondial qu’est Internet. Son successeur, IPv6, existe depuis bientôt 20 ans (1995 !), mais reste encore aujourd’hui marginal malgré la pénurie toujours plus pressante d’adresse IPv4. Ce constat devient plus alarmant chaque année : il va être temps de faire un choix !
Malgré les nombreuses méthodes mises en place afin de prolonger, plus ou moins artificiellement, la durée de vie d’IPv4 (CIDR, NAT, …), et ainsi permettre de déployer progressivement IPv6, celui-ci demeure encore aujourd’hui largement marginal avec seulement environ 1% du trafic mondial. Ces déploiements se sont légèrement accrus depuis l’annonce, en février 2011 par l’IANA, de l’exhaustion du pool global d’adresses IPv4. Les seules réserves restantes sont aux mains des différentes autorités régionales ou RIR (Regional Internet Registry), mais elles ne dureront pas éternellement.
Statistiques Google IPv6 et état de la pénurie IPv4
Selon l’Internet Society lors de sa dernière réunion le 17 avril 2013 à Denver (Colorado), nous sommes arrivés à un embranchement important, puisqu’au regard des prédictions de pénurie pour chaque RIR (notamment les plus gros consommateurs actuels qui sont le RIPE NCC, l’APNIC et l’ARIN), il est déjà trop tard pour envisager une « simple » transition/cohabitation entre IPv4 et IPv6, la réserve d’adresses IPv4 n’étant plus suffisante pour permettre à IPv6 d’être déployé et utilisé en masse avant leur total exhaustion.
Des approches, que nous avions appelées compressives ou translatives dans la série d’articles relatives à IPv6 et à sa migration, existent, que ce soit via IVI (permettant d’avoir un réseau natif IPv6, sans dual-stack, avec une translation 1 à 1 vers le réseau IPv4) ou au travers de CGN (Carrier-Grade NATs, solution qui semble être privilégiée par un certain nombre d’acteurs à l’heure actuelle). Cette dernière, outre les problèmes techniques qu’elles engendrent, « cassant » certaines applications, pose le même problème que les NAT classiques en leur temps : la durée de vie d’IPv4 est encore rallonger de manière artificielle et peu efficace sur le long terme.
Aujourd’hui toutefois, il n’est plus possible de s’en passer. La Chine, grosse consommatrice d’adresses IP depuis quelques années, a déjà dû recourir à certaines de ces méthodes (IVI notamment). Certains fournisseurs d’accès européens envisagent l’ajout de CGN dans leur réseau afin de retarder l’échéance. Le choix qui sera majoritairement fait à ce niveau de la cohabitation déterminera ce qu’il adviendra d’IPv6 : solution tournée vers l’avenir, elle ne pourra être viable que si tous les acteurs décident de s’y impliquer sérieusement. L’ajout de CGN sur le réseau ne doit être qu’une méthode pour gagner encore un peu de temps, mais ne représente en aucun cas une solution à long terme.
Les CGN et Internet (source: Geoff Huston de l’APNIC via potaroo.net)
IPv6 est la solution à long terme, la vision d’avenir promise depuis plusieurs décennies. Il est temps de s’y mettre sérieusement : IPv6 n’est plus seulement une perspective à long terme, le protocole doit devenir une priorité, sans quoi l’Internet tel que nous le connaissons aujourd’hui n’existera plus.
Dans cet objectif, NEXCOM Systems propose un certain nombre de ressources et de compétences sur IPv6 afin d’aider à sa compréhension. Des formations IPv6 abordant le protocole dans le détail (disponible sur un ou deux jours, selon le besoin en connaissances pratiques) ont été conçues afin de comprendre le protocole dans le détail et mieux pouvoir l’appréhender : généralité, adressage, migration v4/v6, etc.
Ces formations sont complétées par des articles, librement disponibles sur notre blog, rappelant les grandes lignes du protocole et des différentes méthodes de migration/translation/cohabitation disponibles. Dans la même idée, nous avons compilé les informations principales du protocole sous une forme concentrée (cheatsheet ou mémo IPv6), également librement disponible sur notre page d’expertise (ou également ici).
Bonne lecture !
25 février 2013
Les notions de sécurité sont souvent mal considérées. Difficiles à comprendre et appréhender, coûteuses à déployer et ayant des résultats parfois variables (mauvaise étude, cas d’usage particulier, …), la sécurité dans les technologies de l’information reste un domaine de niche dans lequel peu s’aventurent. Elle représente en effet un travail considérable… Mais dont l’absence peut mener à des résultats désastreux (vols de données sensibles, indisponibilité prolongée de service, …) ayant des répercutions souvent catastrophiques (coût financier, par exemple, mais pouvant aller jusqu’à la disparition pure et simple d’une entreprise selon les données volées par exemple).
Pourtant, et en se focalisant sur le domaine qui nous intéresse ici directement, il existe aujourd’hui des solutions de chiffrement de trafic IP standardisées et efficaces. Deux méthodes générales peuvent être listées :
- Symétrique : une unique clé est partagée et sert à la fois à chiffrer et déchiffrer le trafic.
- Asymétrique : chaque entité dispose de deux clés, l’une servant à chiffrer (clé publique) alors que l’autre permet de déchiffrer le trafic (clé privée).
Chiffrement symétrique
Le premier type est simple d’utilisation et d’implémentation. Il offre de plus d’excellentes performances lorsqu’il s’agit de chiffrer/déchiffrer du trafic, la même clé servant aux deux usages. Il est fréquemment mis en œuvre dans des installations de type SOHO (Simple Office, Home Office) et se retrouve dans des solutions « grand public » (par exemple dans les WiFi sécurisés en WPA-PSK ou Pre-Shared Key).
En pratique toutefois, il montre rapidement ses limites pour plusieurs raisons :
- La clé doit être échangée à un moment donné. Et cet échange peut être intercepté, rendant le chiffrement inutile…
- La clé est définie par un des participants, et n’est pas renouvelée automatiquement, la rendant plus vulnérable à des attaques par dictionnaire, par exemple.
Plus la clé symétrique est longue, plus ce second point est atténué. Toutefois, plus la clé est longue, plus le premier point peut devenir contraignant… Ce n’est donc pas une solution viable à long terme.
Chiffrement asymétrique et hybride
Le chiffrement asymétrique, de son côté, est sensiblement plus complexe (quatre clés au lieu d’une seule, chiffrement/déchiffrement bien plus coûteux en ressources, …). Contrairement au chiffrement symétrique, cette approche offre le meilleur niveau de sécurité grand public connu actuellement, proposant une théorique inviolabilité jamais contestée jusqu’à présent (sauf dans le cas de problèmes d’implémentation, liés souvent à une génération prévisible de nombres aléatoires).
Si la clé publique, comme son nom l’indique, peut être distribuée à n’importe qui (elle ne peut servir à rien d’autre qu’au chiffrement et à l’identification), la clé privée, elle, doit impérativement rester secrète sans quoi tout l’intérêt de cette technique disparaît. Toute personne en possession de cette clé peut en effet facilement usurper l’identité du possesseur originel.
A titre d’exemples, RSA (conçu en 1977 et nommée après ses inventeurs, R. Rivest, A. Shamir and L. Adleman) et DH (1976, également du nom de ses inventeurs, W. Diffie et M. Hellman) sont tous deux des algorithmes se reposant sur ce principe d’asymétrie. Les certificats standardisés x.509 représentent la forme la plus courante de distribution de clés publique/privée.
Son coût élevé en ressources pour chiffrer/déchiffrer le trafic ne lui permet malheureusement pas d’être utilisé pour chiffrer de grandes quantités de données. Des méthodes « hybrides » ont été créées afin de palier à ce problème et coupler les avantages du chiffrement symétrique et asymétrique. Le fonctionnement de cette approche est représenté ci-dessous de manière (très) simplifiée DON’T PANIC ! 😉
- Alice demande une connexion sécurisée avec Bob.
- Bob transmet, de manière non sécurisée, son certificat, à savoir sa clé publique. Le fait que le médium ne soit pas sécurisé n’est donc pas un problème ici, tout le monde pouvant demander l’accès à cette clé.
- Alice récupère la clé publique de Bob et authentifie celui-ci. La connexion est refusée si cette identité ne peut être vérifiée.
- Par des procédés cryptographiques dans lesquels nous n’allons pas nous engager ici (à base de très grands nombres premiers aléatoires que les deux entités s’échangent… Je vous passe les détails mais vous conseille cet excellent article publié sur Ars Technica [EN] très récemment), Alice génère une Pre-Master Key.
- Cette clé ainsi que la clé publique d’Alice sont transmises à Bob. Le secret de la Pre-Master Key doit être préservé pour assurer l’efficacité de la méthode. Alice possédant la clé publique de Bob, elle l’utilise pour chiffrer son message.
- A la réception du message chiffré, Bob utilise sa clé privée pour déchiffrer le message, chiffré avec sa clé publique par Alice. Il en extrait deux éléments : la clé publique d’Alice et, encore plus important, la Pre-Master Key.
- Bob authentifie Alice à l’aide de sa clé publique. Si l’identité est vérifiée correctement, la négociation est terminée. Ce message peut être transmis de manière sécurisée grâce à la clé publique d’Alice. Celle-ci utilise alors sa clé privée pour décoder le message.
- Dans le même temps, les deux parties génèrent la même clé maître (Master Key) finale via des procédés cryptographiques. De cette clé, ils peuvent en déduire une clé de session identique (et donc symétrique). Cette clé est régénérée régulièrement afin d’éviter les problèmes inhérents aux clés symétriques.
- Cette clé de session symétrique permet de chiffrer efficacement le trafic entre les deux entités, sans la surcharge imprimée par un chiffrement asymétrique.
Cette méthode prend avantage des deux approches : d’un côté, le chiffrement asymétrique permet, au travers d’un médium non sécurisé (Internet, …), de sécurisé les données échangées afin de générer dynamiquement, sans avoir besoin de l’échanger directement, une clé symétrique permettant de chiffrer un trafic important. Cette clé symétrique étant renouvelée régulièrement, elle ne peut être devinée facilement avec les moyens actuels.
Ce type de chiffrement, dit mutuel puisque chacun peut être authentifié à l’aide de son certificat, se retrouve généralement dans des applications nécessitant un niveau de sécurisation très pointu. Il est toutefois prévu que WebRTC, cette technologie dont nous avons déjà abordé dans ce blog précédemment (ici, là ou encore dans le cadre de notre formation WebRTC), chiffre le trafic temps-réel à l’aide de cette méthode via DTLS (Datagram Transport Layer Security), soit du TLS sur UDP.
Une version « allégée » de cette méthode est utilisée beaucoup plus couramment lors de l’accès à des sites Web sécurisés (une banque ou un site marchand, par exemple). Seul le serveur dispose dans ce cas d’un certificat, qui permet au client de certifier qu’il se connecte effectivement au bon site. Le client, lui, ne dispose pas de certificat, mais le fonctionnement reste globalement le même : la Pre-Master Key est toujours transmise (point 5) de manière sécurisée, le client disposant ici aussi de la clé publique du serveur, protégeant ainsi un des principaux secrets de la méthode. Une clé symétrique est générée de la même manière pour chiffrer la session entre le client et le serveur sécurisé.
Oui, mais…
Si ce chiffrement semble idéal en bien des points, il est judicieux de s’interroger sur les certificats en eux-mêmes : comment être sûr qu’un certificat appartient bien à une entité donnée ? Diverses méthodes existent, soit en faisant appel à une infrastructure centralisée (PKI ou Public Key Infrastructure), soit en utilisant un système décentralisé basé sur la création de réseaux de confiance, tel que le prône certaines technologies comme PGP (Pretty Good Privacy), mais également WebRTC !
Mais tout ceci est un sujet à part entière que nous aborderons prochainement dans un nouvel article ! So stay tuned !
Mise à jour (2013-03-01) :
Une erreur (récurrente) s’était glissée dans ce post. Le terme « chiffrage », s’il est accepté par l’académie française pour parler de ce sujet, n’est pas le terme français reconnu. « Chiffrement » doit être utilisé en lieu et place. Ces deux termes sont toutefois très proches, mais dans un souci de précision, la correction a été apportée à l’article. A noter que si « chiffrage » et « chiffrement » sont très proches, « cryptage » (et en particulier « décryptage ») a une toute autre signification, puisque ce terme est uniquement utilisé lorsqu’une personne n’ayant pas les bonnes clés tente de déchiffrer un message donné.
La terminologie dans le domaine de la sécurité : toute une histoire 😉
12 février 2013
Depuis notre précédent article traitant de WebRTC, le framework a continué son évolution à un rythme régulier, notamment au travers de l’API PeerConnection (renommée RTCPeerConnection pour l’occasion) que nous avions déjà mentionnée précédemment. Cette API se précise de jours en jours et devient désormais parfaitement utilisable par les premières applications WebRTC. Attention toutefois : elle demeure encore dans un état de chantier avancé et est donc susceptible d’évoluer très rapidement !
Son support s’est également étendu : outre Google et son navigateur Chrome, dont même les versions « stables » classiques supportent cette API, Mozilla a rejoint le peloton de tête avec les versions de développement de Firefox, à savoir Aurora et ses nightlies. Le support de l’ensemble est encore très expérimental, mais les résultats actuels sont déjà probants.
Qu’en est-il de l’interopérabilité ? Les navigateurs continuent-ils de proposer des APIs préfixées (respectivement webkit-et moz-) ? Peuvent-ils toutefois fonctionner ensemble sur un même service ? La réponse à ces questions est simple et peut être résumée pratiquement en un mot : oui.
Oui, l’interopérabilité, malgré leurs différences d’implémentation, est possible Et a été prouvée récemment par Google et Mozilla qui sont parvenus à faire communiquer Chrome avec les versions de développement de Firefox. La démonstration utilisée est librement disponible pour quiconque souhaiterait vérifier ces dires !
De quoi rabattre les mauvaises langues qui doutaient que cela puisse être possible. Et une belle preuve de l’avenir de cette technologie, même encore balbutiante !
Qu’en est-il des autres navigateurs ?
- Opera, fidèle à son habitude, attendra d’avoir une version mieux figée de l’API avant d’envisager l’intégrer à son navigateur phare.
- Microsoft s’est lancé dans un fork de la technologie, sous des couverts de simplification pour les développeurs des futurs services.
- Apple reste muet quant à une éventuelle implémentation du framework au sein de son navigateur, Safari.
Dans le cas de ces deux derniers, de nombreuses suppositions peuvent être exposées : tous deux peuvent avoir par exemple des intérêts à ne pas promouvoir trop fortement WebRTC, notamment à cause de leurs services respectifs, Skype et FaceTime. Mais toute conjecture est inutile : seul l’avenir pourra déterminer quel choix était le bon. Chacun des acteurs autour de WebRTC a des raisons d’agir comme il le fait.
Afin de démêler l’ensemble de ces sujets tant contextuels que techniques, NEXCOM Systems propose depuis 2013 une nouvelle formation WebRTC, au contenu pertinent : comprendre le cadre pour lequel WebRTC a été prévu, comprendre les tenants et aboutissants de chacun des acteurs, tout en abordant des aspects plus techniques de la technologie (APIs, transport, …). Cette formation WebRTC est prévue pour permettre à chacun de mieux cerner ce qui fera peut-être partie, demain, de notre environnement technologique quotidien. N’hésitez pas à nous contacter pour avoir plus d’informations !
6 juin 2012
Il y a une année pratiquement jour pour jour, le 8 juin 2011, un événement similaire avait eu lieu, sous la forme d’une expérimentation de lancement d’une durée d’une journée. De grands noms de l’industrie avaient participés : Google, Facebook, Yahoo!, … Les résultats de ces tests ont prouvé qu’une partie non négligeable du réseau global, et en particulier de Websites majeurs, était capable de passer, sans encombre, à IPv6. (suite…)
5 juin 2012
Afin de succéder à IPv4, il est question de déployer l’Internet Protocol dans sa version 6 depuis de très nombreuses années maintenant. Des moyens importants ont été mis en œuvre afin de préserver autant que possible IPv4 (notamment au travers des NAT). Nous sommes toutefois arrivés à un point de non-retour : le pool d’adresses publiques IPv4 est désormais épuisé au niveau mondial. (suite…)
5 juin 2012
La transition entre IPv4 et IPv6 se rapproche toujours un peu plus, et il convient de se préparer à aborder cette transition au mieux. Le cadre le plus intéressant à considérer ici dans le monde de la ToIP (Telephony over IP) se repose sur l’utilisation du protocole SIP (Session Initiation Protocol), majoritairement utilisé à l’heure actuelle et en voie de devenir toujours plus important à l’avenir. Le déploiement de IPv6 se fera progressivement, et il y aura obligatoirement une période plus ou moins longue pendant laquelle IPv4 cohabitera avec IPv6. Si IPv6 n’apporte aucun réel changement par rapport à IPv4 dans le fonctionnement général des réseaux, ces deux protocoles sont néanmoins incompatibles directement, et il est nécessaires de pouvoir effectuer une transition de la manière la plus transparente possible.
(suite…)
5 juin 2012
Après avoir traité des approches hybrides (tunneling) puis compressives (mapping), ce dernier article va discuter du dernier type de options actuellement disponibles, sous la forme de solutions translatives allant faire la traduction entre les deux versions du protocole IP (protocol translation).
(suite…)
5 juin 2012
Au cours de la première partie, nous avions commencé à aborder les différentes options de déploiement IPv6 disponibles pour les opérateurs avec les méthodes de type hybride/tunneling. Dans le présent article, nous allons poursuivre cette étude en observant une approche quelque peu différente, puisque tentant ici de rationaliser l’usage des adresses IPv4 afin de limiter l’hémorragie et de pouvoir continuer à fournir un service IPv4 dans les années à venir tout en migrant progressivement vers IPv6.
Certaines de ces solutions, nous allons le voir, essaient de coupler l’aspect préservation avec l’aspect migration, mais il est souvent nécessaire de combiner ces approches avec d’autres protocoles de transition afin d’avoir et une solution de migration vers IPv6, et une solution de préservation d’adresses IPv4
(suite…)
5 juin 2012
Nous l’avons vu dans cet article sur les solutions à disposition des clients afin d’obtenir une connectivité IPv6, mais il s’avère désormais que la gestion des différentes problématiques, relative tant à la pénurie d’adresses IPv4 qu’à la migration vers IPv6, vont incomber en grande partie aux fournisseurs d’accès.
Les opérateurs disposent d’un large choix de solution, leur permettant de sélectionner la meilleure approche possible au regard de leur infrastructure et de l’approche qu’ils envisagent pour aborder ces problématiques. Au regard du nombre d’options possibles, nous allons exposer ces différentes solutions au travers de trois articles successifs, en abordant en premier lieu les solutions hybrides (tunneling) avant de traiter successivement les approches compressives et translatives.
(suite…)
5 juin 2012
Le risque de pénurie d’adresses IPv4 devient de plus en plus présent avec les mois qui s’écoulent. Des solutions temporaires avaient été apportées avec les NAT, mais il est désormais essentiel de préparer une migration la plus rapide possible vers IPv6 tout en devant gérer cette pénurie, ce qui ne facilite en rien le travail de transition IPv4-IPv6.
De (très) nombreuses solutions ont été imaginées et proposées ces dernières années afin de tenter d’apporter une solution efficace et (relativement) facile à mettre en œuvre afin d’assurer cette transition. Ce choix est une bonne nouvelle puisqu’il va permettre de choisir la méthode la plus appropriée au cas de figure considéré. Ce qui est malheureusement aussi une mauvaise nouvelle puisque cette débauche de solutions engendre un problème de taille : quelles sont les solutions optimales et pour quels cas de figure ?
Ces solutions peuvent être classées en deux écoles différentes : soit la transition est assurée majoritairement au niveau du client, soit cette transition est effectuée par le fournisseur d’accès. Nous commencerons par décrire les approches possibles au niveau des utilisateurs finaux (clients) avant d’aborder, dans un prochain article, les mécanismes offerts aux fournisseurs d’accès.
(suite…)
5 juin 2012
Nous avons précédemment discuté des notions de syntaxe et de classification des adresses IPv6. Il reste toutefois encore un sujet à aborder dans ce domaine, la question de l’adressage en lui-même. Il ne sera pas ici question d’effectuer un plan d’adressage, mais bel et bien des contraintes entourant la distribution et la confection des adresses IPv6 pour chaque entité du réseau.
(suite…)
5 juin 2012
Depuis les débuts du protocole Internet (Internet Protocol ou IP), la plage complète d’adresses ont toujours été classifiées dans différents rôles et usages. Ces rôles ont évolués au fil du temps, et ont été remis à jour avec l’arrivée d’IPv6.
(suite…)