Archives par mois : février 2013

Les solutions de chiffrement en réseaux télécoms et Web/WebRTC

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 ! 😉

  1. Alice demande une connexion sécurisée avec Bob.
  2. 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é.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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,  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 😉

WebRTC : l’interopérabilité en ligne de mire !

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 !

XURA 90H
setelia
alten
TuffigoRapidex
SFR
BureauVeritas
orange
athemium
cirpack
VA SOLUTIONS2
sagemcom
Lomaco
Schneider-mod
HubOne
logo-coriolis-telecom_mod
NETENSIA
NIJI
econocom
DGAC
Thales
Adeunis
SopraSteria
DCNS
assystem-logo
nokia-logo
Monaco Telecom_550x550
Keolis
Deltadore
AXIANS
t&t
broadpeak
LOGO-CONVERGENCE-2019_300px_mod
Motorola
Extia
Savelec
adventiel
ADP
sierra_wireless
la poste
intel
Italtel
akio
SNCF_2011
iagility
CGI
capgemini
SII
Sofrecom
Groupama-logo
actility
GFI
technicolor
neosoft
axione
Modis
AIRBUS
ESR Groupe H69
Viibe
Amphenol-Antenna-Solutions-Logo-2-mod
Astellia
Icosnet
engie-ineo
CMB ARKEA
image_et_reseau
davidson
Bouygues E&S
logo_SDIS54_mod