La Fibre

Forum : => La Fibre FTTH (Fiber To The Home) => fibre Technologie Gpon / Le futur: XGS-PON et NG-PON2 => Discussion démarrée par: minidou le 28 janvier 2013 à 18:07:20

Titre: Chiffrement du Gpon
Posté par: minidou le 28 janvier 2013 à 18:07:20
2/ La sécurité : contrairement au P2P où il est facile et peu coûteux d'écouter un voisin en sniffant au point de connexion, en Gpon, les informations sont cryptées et ce cryptage n'est pas encore cassé. Donc le Gpon est plus sécurisé que le P2P.
Comment ça se passe exactement ce cryptage?
Titre: Chiffrement du Gpon
Posté par: Snickerss le 28 janvier 2013 à 18:12:12
"Chiffrement"

J'imagine que c'est ta box qui possède la clé privée pour déchiffrer les donnes envoyées chiffrées avec ta clé publique par l'équipement actif du FAI
Titre: Chiffrement du Gpon
Posté par: tit91 le 29 janvier 2013 à 00:15:04
L'ONT, plus précisèment. Le petit boîtier noir blanc chez Orange.
Titre: Chiffrement du Gpon
Posté par: corrector le 29 janvier 2013 à 00:17:15
Je ne connaissais pas ce système; cela correspond à quelle norme?
Titre: Chiffrement du Gpon
Posté par: tit91 le 29 janvier 2013 à 00:21:20
À GPON. Le trafic est chiffré entre l'OLT (au NRO/NRA) et l'ONT (chez l'abonné), ce dernier étant placé entre la box et la fibre... un convertisseur de média (pour rester en français) évolué.
Titre: Chiffrement du Gpon
Posté par: corrector le 29 janvier 2013 à 00:27:29
"Chiffrement"
Merci.

C'est pas faute de l'avoir dit.

C'est ta box qui possède la clé privée pour déchiffrer les donnes envoyées chiffrées avec ta clé publique par l'équipement actif du FAI
Tu peux détailler cette histoire de clé publique?

C'est quel chiffre?
Titre: Chiffrement du Gpon
Posté par: seb le 29 janvier 2013 à 00:48:49
C'est quel chiffre?
Du ElGamal, probablement, puisque l'algorithme n'est couvert par aucun brevet (il est utilisé par GnuPG).

Si je comprends bien, quand on raccorde l'ONT au réseau, il transmet sa clé publique à l'OLT, qui chiffre ensuite avec tout le trafic à destination de l'ONT ?
Je suppose qu'il doit bien y avoir une phase de négociation en clair entre les deux, avant que la liaison ne devienne chiffrée, et j'imagine que si l'on se met à l'écoute de ce trafic en clair diffusé sur tout l'arbre, il doit y avoir moyen de "pourrir" la négociation afin de détourner tout le trafic vers son propre ONT.
Ça doit être rigolo de planter tout l'arbre.  8)

Titre: Chiffrement du Gpon
Posté par: corrector le 29 janvier 2013 à 00:53:59
Heu... l'intérêt la crypto asymétrique, c'est bien de pré-installer des clefs privées différentes dans chaque ONT et d'ancrer tout le protocole sur cette clé privée.
Titre: Chiffrement du Gpon
Posté par: seb le 29 janvier 2013 à 01:02:02
Il faut bien que la clé publique de l'ONT soit transmise à l'OLT pour que le chiffrement puisse avoir lieu.
J'ai beaucoup de mal à croire que les clés publiques des ONT sont codées en dur dans l'OLT : ça rendrait l'échange d'ONT vraiment compliqué.
L'hypothèse d'une phase de négociation en clair, avec transmission de la clé publique me semble beaucoup plus probable ...
Titre: Chiffrement du Gpon
Posté par: corrector le 29 janvier 2013 à 01:08:02
Il faut bien que la clé publique de l'ONT soit transmise à l'OLT pour que le chiffrement puisse avoir lieu.
Il faut bien un provisioning! Puisque les opérateurs gèrent le provisioning des box, pourquoi pas des ONT?

S'il n'y a pas de provisioning, comment authentifier les ONT?

J'ai beaucoup de mal à croire que les clés publiques des ONT sont codées en dur dans l'OLT : ça rendrait l'échange d'ONT vraiment compliqué.
Si on peut échanger les ONT, sans les merdes du provisioning foireux, ça veut dire que les ONT ne sont pas authentifiés.

L'hypothèse d'une phase de négociation en clair, avec transmission de la clé publique me semble beaucoup plus probable ...
Donc il n'y a aucune ancre?
Titre: Chiffrement du Gpon
Posté par: seb le 29 janvier 2013 à 01:10:45
Il me semble bien avoir vu sur ce site des copies d'écran de l'interface (web ?) d'un ONT au niveau de laquelle on configurait le provisioning.
Titre: Chiffrement du Gpon
Posté par: minidou le 29 janvier 2013 à 01:24:42
Merci.

C'est pas faute de l'avoir dit.
Tu peux dire ce que tu veux mais j'ai encore le droit d'utiliser un anglicisme si ça me chante
Je suppose qu'il doit bien y avoir une phase de négociation en clair entre les deux
C'est surtout ça qui m'intéresse
Titre: Chiffrement du Gpon
Posté par: corrector le 29 janvier 2013 à 01:28:08
Que signifie "crypter" alors?
Titre: Chiffrement du Gpon
Posté par: Snickerss le 29 janvier 2013 à 02:19:42
Je crois que j'avais expliqué qu'en recherche "crypter" signifiait "masquer des données" sans clé de chiffrement. Quand on "décrypte" des donnés, on n'a pas la clé pour. C'est de la recherche. Déchiffrer : on applique l'algo avec la bonne clé et on obtient le bon résultat :) pas tout a fait le même sens.

Concernant les clés publiques privées, l'échange se fait en clair mais ne compromet pas la sécurité, tant qu'on ne saura pas factoriser des grands nombres. La clé public est une clé accessible par tous, qui permet de chiffrer des donnees que seul le possesseur de la clé privée pourra déchiffrer. Ainsi même avec cette clé public, une fois la donnée chiffre tu ne pourras rien en faire.
Titre: Chiffrement du Gpon
Posté par: corrector le 29 janvier 2013 à 02:24:23
Comment la clé publique est distribuée dans ce système?

Lors du provisioning?
Titre: Chiffrement du Gpon
Posté par: Snickerss le 29 janvier 2013 à 02:33:37
Je ne suis pas du tout un spécialiste du GPON, j'aurais du préciser que c'était comment je voyais le système, puisque l'on a besoin d'un chiffrement dans un sens seulement. D'après wiki, c'est un chiffrement symétrique (AES, pour des raisons de performance très probablement, le chiffrement asymétrique étant beaucoup plus coûteux)

Aucune idée de comment sont configurés les ont
Titre: Chiffrement du Gpon
Posté par: corrector le 29 janvier 2013 à 02:44:04
Si le chiffrement n'est que dans le sens descendant, ça veut dire que la sécurité du GPON vantée par vivien n'est pas là : on peut aller au point de flexibilité pour enregistrer les cookies de connexion utilisés sur lafibre.info pour les connexions HTTP, et poster des messages en utilisant l'identité d'un autre sur le forum!

Par ailleurs je me demande si on peut se faire passer pour un autre utilisateur de l'arbre GPON.
Titre: Chiffrement du Gpon
Posté par: Snickerss le 29 janvier 2013 à 02:59:15
De ce que j'ai pu lire récemment, la norme du GPON rend impossible la connexion d'un ont clandestin de façon invisible, et il y aurait changement des clés plusieurs fois / jour.

Complique de trouver des articles intéressant qui rentrent dans le sujet. Même le "livre blanc sur les réseaux pon" par de cryptage/décryptage (sic) (1er résultat dans google : livre blanc pon)
Titre: Chiffrement du Gpon
Posté par: Leon le 29 janvier 2013 à 06:49:25
Bon, quand vous aurez fini vos échanges sur le cryptage du GPON, est-ce que vous pourez nous faire une synthèse? Avec des propos compréhensibles? Parce que j'ai beaucoup de mal à vous suivre. Je n'y connais pas grand chose, mas ça m'intéresse.

Leon.
Titre: Chiffrement du Gpon
Posté par: vivien le 29 janvier 2013 à 08:21:23
Pour moi, le chiffrement se fait dans les deux sens : chaque  OLT et chaque ONT ont  une clé privée / clé publique pour le chiffrement.
Titre: Chiffrement du Gpon
Posté par: tit91 le 29 janvier 2013 à 11:42:17
La seule chose que le technicien configure sur place à l'installation de l'ONT, c'est un "password". Ici sur un ONT Huawei:

TERMINAL(gpon)#passwd
[usage]:
 passwd set xxxxxxxxxx
 passwd get
 ?


Je ne suis pas certain que cela suffise pour identifier un ONT sur l'arbre, peut-être que d'autres éléments interviennent telle son adresse MAC par exemple.
Titre: Chiffrement du Gpon
Posté par: minidou le 29 janvier 2013 à 14:10:53
Pour moi, le chiffrement se fait dans les deux sens : chaque  OLT et chaque ONT ont  une clé privée / clé publique pour le chiffrement.
J'ai fait une recherche (très) rapide, et il semblerait qu'en GPON, seul le débit descendant soit chiffrée, contrairement au passive ethernet, ou les deux flux le sont
dans les deux cas, de l'AES-128 (ou 192/256 suivant le matos)

Cela voudrait dire qu'en reprenant ton idée d'observer le traffic au point d'arrivé d'immeuble, le GPON n'est pas vraiment plus sécurisé que le P2P
Titre: Chiffrement du Gpon
Posté par: corrector le 29 janvier 2013 à 16:47:30
contrairement au passive ethernet, ou les deux flux le sont
Ah bon?
Titre: Chiffrement du Gpon
Posté par: Skyhawk le 29 janvier 2013 à 18:10:19
Est-on sur que les opérateurs cryptent le flux?
Quelqu'un a déjà écouté un arbre GPON?

Entre ce que dit la norme (je suis même pas sur que le chiffrement soit imposé) et ce que les opérateurs mettent en place pour des raisons pratiques et/ou économiques, il doit y avoir un petit gouffre quand même :p


Peut-être que la norme prévoie le chiffrement, ce qui impose donc l'enregistrement de la clé publique en usine, mais que les opérateurs ne l'ont pas mis en place pour simplifier les choses en jugeant le risque de piratage comme minime.
Titre: Chiffrement du Gpon
Posté par: Snickerss le 29 janvier 2013 à 18:24:19
Est-on sur que les opérateurs cryptent le flux?
Quelqu'un a déjà écouté un arbre GPON?

Entre ce que dit la norme (je suis même pas sur que le chiffrement soit imposé) et ce que les opérateurs mettent en place pour des raisons pratiques et/ou économiques, il doit y avoir un petit gouffre quand même :p


Peut-être que la norme prévoie le chiffrement, ce qui impose donc l'enregistrement de la clé publique en usine, mais que les opérateurs ne l'ont pas mis en place pour simplifier les choses en jugeant le risque de piratage comme minime.


Tout bonnement impossible que le flux ne soit pas chiffré dans le sens montant. C'est dans la norme.
Titre: Chiffrement du Gpon
Posté par: Leon le 29 janvier 2013 à 18:28:42
contrairement au passive ethernet, ou les deux flux le sont
C'est quoi le "Passive Ethernet"? C'est le P2P de type Free?
Si c'est ça, il n'est pas chiffré-crypté, il suffit de regarder les tests qu'on pu faire les geeks de ce forum en se branchant sans Freebox.

Leon.
Titre: Chiffrement du Gpon
Posté par: corrector le 29 janvier 2013 à 19:19:57
... pas chiffré-crypté, sauf peut-être la TV et le tél.
Titre: Chiffrement du Gpon
Posté par: thenico le 29 janvier 2013 à 22:26:30
Tout bonnement impossible que le flux ne soit pas chiffré dans le sens montant. C'est dans la norme.

Le BPI fait partie de DOCSIS mais il n'est pas activé chez Numericable.
Effectivement, il faudrait tester la réalité de la chose.
Titre: Chiffrement du Gpon
Posté par: vivien le 29 janvier 2013 à 22:39:17
En FTTH Point à point ou en câble, il est facile de sniffer le trafic (matériel dans le commerce est pas trop cher).

En Gpon, si vous avez une solution a moins de 300€, je suis preneur...
Titre: Chiffrement du Gpon
Posté par: corrector le 29 janvier 2013 à 23:11:18
En FTTH Point à point ou en câble, il est facile de sniffer le trafic (matériel dans le commerce est pas trop cher).
En câble, on peut facilement sniffer le trafic dans les deux sens?
Titre: Chiffrement du Gpon
Posté par: JulFX le 29 janvier 2013 à 23:46:56
La seule chose que le technicien configure sur place à l'installation de l'ONT, c'est un "password". Ici sur un ONT Huawei:

TERMINAL(gpon)#passwd
[usage]:
 passwd set xxxxxxxxxx
 passwd get
 ?


Je ne suis pas certain que cela suffise pour identifier un ONT sur l'arbre, peut-être que d'autres éléments interviennent telle son adresse MAC par exemple.
Un technicien fibre mandaté par Orange va:
- Provisionner le mot de passe de l'ONT et coller une étiquette sur l'ont avec ce mot de passe. (à ne pas confondre avec un numéro de téléphone)
- Mettre l'identifiant et le mot de passe de la session ppp dans la livebox
- Paramétrer un équipement client, 90% du temps en wifi, dont la clé est fournie (derrière la livebox et sur le livret)
- Il peut bien sur récupérer l'adresse mac de la livebox et de l'ont sur leur étiquettes respectives, et l'atténuation PM-PTO.

Il est donc en mesure:
- Installer n'importe quel malware sur l'équipement du client
- Se connecter sur son réseau wifi
- Paramétrer un ont et une livebox pour aller se brancher au PM, sur la position du client.
- Pour que ce ne soit pas détectable coté opérateur, il faut que l'atténuation soit identique, et être en mesure de changer l'adresse mac de l'ont et la livebox.
Titre: Chiffrement du Gpon
Posté par: corrector le 30 janvier 2013 à 00:20:21
Pourquoi pré-paramétrer une passphrase Wifi? Quel intérêt?
Titre: Chiffrement du Gpon
Posté par: vivien le 30 janvier 2013 à 08:28:25
Simplifier la vie au client (surtout si il ne possède pas de périphérique avec carte Ethernet, comme les derniers MacBook Air qui sont sans carte Ethernet)

Pour le câble il est coûteux de sniffer le trafic montant mais pas le descendant (une carte TV DVB-C par canal permet de le faire)
Titre: EAP-TLS sur les box
Posté par: corrector le 30 janvier 2013 à 09:09:50
Ah.

On ne pourrait pas avoir un WPA-Enterprise en EAP-TLS avec les identifiants de connexion?

De façon générale, je pense qu'il faut généraliser EAP-TLS sur les box.
Titre: Chiffrement du Gpon
Posté par: minidou le 30 janvier 2013 à 16:21:55
au FIC 2013 (5ème Forum International de la CyberSécurité) il y avait apparemment la démonstration d'un boitier d'interception de données passant par FO

(http://datasecuritybreach.fr/wp-content/uploads/2013/01/Fic14.jpg)

Par contre, je n'y étai spas et suis bien incapable de trouver qui l'a amené, et s'il y a eu une conférence à se sujet
de toute façon ils ne semble pas y avoir de diffusion des conférences (présentation ou white paper)
Titre: Chiffrement du Gpon
Posté par: sanguinarius le 01 février 2013 à 23:09:57
Plop

Moi j'y etais :)

Donc c'est un boitier standard de 20 € comme on peut trouver pour le cuivre, c'etait presenter par alcatel lucent, la presentation (seulement sur leur stand) etait en faite orienté sur la solution pour detecter ce genre d'attaque. Sauf comme j'ai pu leur demontrer lors de l'event il suffit de rehausser le signal pour que leur outil ne detecte plus rien :)

L'idée est bonne mais imho ya des details a paufiner :)
Titre: Chiffrement du Gpon
Posté par: corrector le 01 février 2013 à 23:15:36
Donc c'est un boitier standard de 20 € comme on peut trouver pour le cuivre, c'etait presenter par alcatel lucent, la presentation (seulement sur leur stand) etait en faite orienté sur la solution pour detecter ce genre d'attaque. Sauf comme j'ai pu leur demontrer lors de l'event il suffit de rehausser le signal pour que leur outil ne detecte plus rien :)
La mesure de la puissance du signal a aussi été proposée comme méthode pour détecter les faux AP WEP, à l'époque où on essayait encore de "sécuriser" le WEP afin d'utiliser du matos pas compatible WPA. Bien sûr ça ne fonctionne que si l'attaquant ne tient pas compte de ce moyen de détection!

En fin de compte on en arrive toujours à la conclusion que seule la cryptographie correctement implèmentée permet de contrer les attaques.
Titre: Chiffrement du Gpon
Posté par: miky01 le 02 février 2013 à 11:31:31
L'hypothèse d'une phase de négociation en clair, avec transmission de la clé publique me semble beaucoup plus probable ...

Faire ca, c'est la meme chose que si tu écris le pin code de ta carte de crédit dessus, ou que tu metsun mot sur ta porte "la clé est sous le paillasson" ...
Titre: Chiffrement du Gpon
Posté par: Snickerss le 02 février 2013 à 12:57:12
Bah surtout si les clés changent toutes les x heures comme j'ai pu le lire dans certains articles sur la sécurité du GPON
Titre: Chiffrement du Gpon
Posté par: seb le 02 février 2013 à 13:10:02
Je parlais de clés asymétriques.
Ce n'est pas parce qu'un tiers dispose des clés publiques de A et B qu'il peut déchiffrer leur correspondance.
Ou alors, j'ai raté un épisode ...
Titre: Chiffrement du Gpon
Posté par: Snickerss le 02 février 2013 à 13:52:36
Bah visiblement, le chiffrement est symétrique lors des echanges de donnees. Mais peut être cette clé est chiffre avec un système de chiffrement asymétrique lors de l'échange  :-)
Titre: Chiffrement du Gpon
Posté par: corrector le 02 février 2013 à 19:13:57
Bah visiblement, le chiffrement est symétrique lors des echanges de donnees. Mais peut être cette clé est chiffre avec un système de chiffrement asymétrique lors de l'échange  :-)
On fait toujours comme ça.

On n'utilise jamais la crypto asymétrique pour le flux de données lui-même.

Faire ca, c'est la meme chose que si tu écris le pin code de ta carte de crédit dessus, ou que tu metsun mot sur ta porte "la clé est sous le paillasson" ...
Bingo.
Titre: Chiffrement du Gpon
Posté par: corrector le 02 février 2013 à 19:18:34
Je parlais de clés asymétriques.
Ce n'est pas parce qu'un tiers dispose des clés publiques de A et B qu'il peut déchiffrer leur correspondance.
Ou alors, j'ai raté un épisode ...
L'épisode délicat c'est la distribution des clefs publiques.
Titre: Chiffrement du Gpon
Posté par: Skyhawk le 03 février 2013 à 00:10:54
Si l'OLT envoie à tous les ONT sa clé publique, tout le monde (qui détient la clé publique j’entends) peux crypter, mais seul le propriétaire de la clé privée (dans ce cas l'OLT) peux décrypter. Donc dans ce sens c'est sécurisé.

Maintenant chaque ONT génère son couple de clés, et envoie sa clé publique à l'OLT. L'OLT détient donc l'ensemble des clés publiques pour les ONT. Il peut donc crypter les paquets avec la bonne clé publique, et seul l'ONT qui possède la clé privée associée pourra décrypter le paquet.

C'est pas sécurisé ça?  ???
Titre: Chiffrement du Gpon
Posté par: corrector le 03 février 2013 à 00:32:59
Ta question n'a en soi aucun sens.

Il faut préciser dans quel contexte, face à quels types d'attaques, etc.

"sécurisé" (dans l'absolu), ça n'existe pas!
Titre: Chiffrement du Gpon
Posté par: Skyhawk le 03 février 2013 à 00:39:44
Il faut préciser dans quel contexte, face à quels types d'attaques, etc.

Si quelqu'un écoute un arbre GPON, est il capable de lire les données qui y circulent (dans les deux sens) ?
Titre: Chiffrement du Gpon
Posté par: corrector le 03 février 2013 à 00:41:57
Il écoute au BAB?
Il se branche au boitier de mutu?
Titre: Chiffrement du Gpon
Posté par: Skyhawk le 03 février 2013 à 00:45:30
Par exemple, ou au point de mutualisation, ou n'importe où d'ailleurs entre la sortie optique de l'opérateur et les media-converters des abonnés.
Un arbre GPON bête et méchant quoi.
Titre: Chiffrement du Gpon
Posté par: corrector le 03 février 2013 à 00:54:17
Si l'OLT envoie à tous les ONT sa clé publique,
Il l'envoie quand?
Titre: Chiffrement du Gpon
Posté par: Skyhawk le 03 février 2013 à 00:56:27
Je sais pas moi. L'ONT doit pouvoir en faire la demande quand il se connecte à l'arbre.
Si les clés sont changés tous les jours, toutes les 5 heures ou autre, ben à ce moment là.
Titre: Chiffrement du Gpon
Posté par: corrector le 03 février 2013 à 00:58:55
Il annonce comment?

Comme ça?

ONT_x -> OLT : demande-de-clef-publique
OLT -> ONT_x : annonce-de-clef-publique(Kp)

sans précaution particulière?
Titre: Chiffrement du Gpon
Posté par: Skyhawk le 03 février 2013 à 01:04:02
Oui par exemple. Mais qu'est-ce que ça peut faire?
Si on part du principe que toutes les clés publiques sont connues de tout le monde c'est plus simple.
Ça pose un problème de sécurité?

Je croyais qu'il été impossible de déchiffrer un message sans la clé privée...
Titre: Chiffrement du Gpon
Posté par: corrector le 03 février 2013 à 01:11:43
Oui par exemple. Mais qu'est-ce que ça peut faire?
Tu dis que le protocole a lieu comme je l'ai écrit c'est à dire entièrement en clair (quand il y a chiffrement il faut indiquer chiffre(message,clef)).

Tu dis que ONT_x reçoit une clé sur le fil et après il commence à l'utiliser.

En résumé ONT_x croit sur parole les photons qui sortent de la fibre. Les photons qui viennent de l'OLT. Ou bien?

Si on part du principe que toutes les clés publiques sont connues de tout le monde c'est plus simple.
Si on part du principe qu'un problème est résolu forcèment c'est plus simple.
Titre: Chiffrement du Gpon
Posté par: Bensay le 01 mai 2013 à 10:56:35
Un technicien fibre mandaté par Orange va:
- Provisionner le mot de passe de l'ONT et coller une étiquette sur l'ont avec ce mot de passe. (à ne pas confondre avec un numéro de téléphone)
- Mettre l'identifiant et le mot de passe de la session ppp dans la livebox
- Paramétrer un équipement client, 90% du temps en wifi, dont la clé est fournie (derrière la livebox et sur le livret)
- Il peut bien sur récupérer l'adresse mac de la livebox et de l'ont sur leur étiquettes respectives, et l'atténuation PM-PTO.

Il est donc en mesure:
- Installer n'importe quel malware sur l'équipement du client
- Se connecter sur son réseau wifi
- Paramétrer un ont et une livebox pour aller se brancher au PM, sur la position du client.
- Pour que ce ne soit pas détectable coté opérateur, il faut que l'atténuation soit identique, et être en mesure de changer l'adresse mac de l'ont et la livebox.

Pour la 2ème partie , peut être chez free , mais chez Orange.....
Il y a un minimum de sérieux à avoir quand tu travaille chez un FAI quand même.
Titre: Chiffrement du Gpon
Posté par: corrector le 01 mai 2013 à 13:47:18
Il en a la possibilité technique, ou non?
Titre: Chiffrement du Gpon
Posté par: Bensay le 01 mai 2013 à 14:24:51
Comme tout technicien informatique mandaté par le client , je vois pas pourquoi plus un technicien Orange qu'un autre.
Titre: Chiffrement du Gpon
Posté par: corrector le 01 mai 2013 à 15:16:51
Si l'OLT envoie à tous les ONT sa clé publique, tout le monde (qui détient la clé publique j’entends) peux crypter, mais seul le propriétaire de la clé privée (dans ce cas l'OLT) peux décrypter. Donc dans ce sens c'est sécurisé.

Maintenant chaque ONT génère son couple de clés, et envoie sa clé publique à l'OLT. L'OLT détient donc l'ensemble des clés publiques pour les ONT. Il peut donc crypter les paquets avec la bonne clé publique, et seul l'ONT qui possède la clé privée associée pourra décrypter le paquet.

C'est pas sécurisé ça?  ???
Non.

Si ton adversaire insère son équipement au niveau d'un boitier de flexibilité, il peut envoyer sa propre clé publique que tu vas utiliser à la place de celle de l'ONT.
Titre: Chiffrement du Gpon
Posté par: Bensay le 01 mai 2013 à 16:18:04
Ce n'est qu'une supposition mais je présume que l'OLT s'authentifie d'une manière spéciale.

Bensay
Titre: Chiffrement du Gpon
Posté par: corrector le 01 mai 2013 à 16:21:01
Donc il faut un provisioning des ONT.
Titre: Chiffrement du Gpon
Posté par: Bensay le 01 mai 2013 à 16:42:14
En général le provisioning ce fait chez le client au moment de rentré le mot de passe,
L'OLT redemande ensuite régulièrement le mot de passe (SLID)

(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/doc/201012_ont_alcatel-lucent_7330_manual.jpg) (https://lafibre.info/images/doc/201012_ont_alcatel-lucent_7330_manual.pdf)

Bensay
Titre: Chiffrement du Gpon
Posté par: BadMax le 01 mai 2013 à 21:16:27
Pour vérifier l'authenticité de la clé publique ce n'est qu'un problème d'autorité de certification. Toute usurpation sera détectée.
Titre: Chiffrement du Gpon
Posté par: corrector le 01 mai 2013 à 21:27:13
Quelle est l'autorité de certification? Le constructeur?
Titre: Chiffrement du Gpon
Posté par: BadMax le 01 mai 2013 à 21:57:57
Par exemple.
Titre: Chiffrement du Gpon
Posté par: corrector le 01 mai 2013 à 22:07:15
Donc chaque ONT connait a priori tous les constructeurs d'OLT avec qui il peut avoir à se connecter?
Titre: Chiffrement du Gpon
Posté par: BadMax le 01 mai 2013 à 22:37:22
Ou les constructeurs se mettent d'accord sur une CA commune.

Ou la CA est chargée à l'installation en fonction du constructeur en place.

etc

Titre: Chiffrement du Gpon
Posté par: Bensay le 02 mai 2013 à 01:05:41
Bonsoir,
Les ONT des constructeurs ne sont pas inter-opérable a l'heure actuelle.
Cf : Olt Huawey : Ont Huawey
Olt Alcatel : Ont Alcatel.
Des lors cela simplifie les choses pour l'authentification.
Mais complexifie pour l'intégration.

Bensay
Titre: Chiffrement du Gpon
Posté par: Nico le 02 mai 2013 à 07:31:05
Tu es certain ? Sauf erreur de ma part SFR ne distribue qu'un type d'ONT pour deux constructeurs d'OLT. Par contre ton assertion est vraie pour Orange.
Titre: Chiffrement du Gpon
Posté par: Bensay le 02 mai 2013 à 07:39:41
SFR à t'il 2 constructeurs différents D'OLT ou un unique?
Ceci expliquerais cela.
Bensay
Titre: Chiffrement du Gpon
Posté par: Nico le 02 mai 2013 à 08:02:14
A ma connaissance (ALU et HW), cf. ce que j'ai écrit :

deux constructeurs d'OLT
Titre: Chiffrement du Gpon
Posté par: krtman le 20 mai 2013 à 12:39:32
Voila ce que dit l'ITU sur la sécurité du GPON :

ITU G.984.4 (http://www.itu.int/rec/T-REC-G.984.4/fr) :

7.4 Security management

[ITU-T G.984.3] specifies some mechanisms from the viewpoint of security. That includes the downstream data encryption of the ONT. The ONT2-G managed entity can enable/disable the downstream encryption function.
This Recommendation supports the protection function. The type C protection configuration that is defined in [b-ITU-T G.984.1] is considered in this Recommendation. As the switching behaviour for PON protection will be done in the TC layer, this Recommendation defines a managed entity to specify the protection capability."

[...]

"Security capability: This attribute advertises the security capabilities of the ONT. The following codepoints are defined:
0 Reserved.
1 AES encryption of the downstream payload supported.
2..255 Reserved.
(R) (mandatory) (1 byte)

Security mode: This attribute specifies the current security mode of the ONT. All secure GEM ports in an ONT must use the same security mode at any given time. The following codepoints are defined:
0 Reserved.
1 AES algorithm used for unicast traffic.
2..255 Reserved.

Upon ME instantiation, the ONT sets this attribute to 1, AES. If new encryption modes are standardized, then AES will be the default, and the new modes will be settable via writing to this attribute. This does not mean that any channels are encrypted; that process is negotiated at the PLOAM layer. It only signifies that AES is the security mode to be used on any channels that the OLT may choose to encrypt. (R, W) (mandatory) (1 byte)"


ITU G.984.3 (http://www.itu.int/rec/T-REC-G.984.3/fr) :

12 Security

This clause discusses the data security issues that PON raises. It discusses the threat model that the security is intended to counter. It then discusses the basic key exchange and activation method.

12.1 Basic threat model

The basic concern in PON is that the downstream data is broadcast to all ONUs attached to the PON. If a malicious user were to re-programme his ONU, then he could listen to all the downstream data of all the users. It is this 'eavesdropping threat' that the PON security system is intended to counter. Other, more exotic threats are not considered practically important because, in order to attempt these attacks, the user would have to expend more resources than it would be worth.
Furthermore, the PON itself has the unique property in that it is highly directional. So any ONU cannot observe the upstream traffic from the other ONUs on the PON. This allows privileged information (such as security keys) to be passed upstream in the clear. While there are threats that could jeopardize this situation, such as an attacker tapping the common fibres of the PON, these again are not considered realistic, since the attacker would have to do so in public spaces, and would probably impair the very PON he is tapping.

12.2 Encryption system
The encryption algorithm to be used is the advanced encryption standard (AES). It is a block cipher that operates on 16-byte (128-bit) blocks of data. It accepts 128, 192 and 256 bit keys. This algorithm is described in documents published by the National Institute of Standards and Technology (NIST) in the USA.

There are several modes of operation for this standard; however, only the 'counter' (CTR) mode shall be used [FIPS 81]. The cipher generates a stream of 16-byte pseudo-random cipher blocks which are exclusive-OR'ed with the input clear-text to produce the output of cipher-text. The cipher-text is exclusive-OR'ed with the same pseudo-random cipher blocks to regenerate the cleartext.
Also, the key length is fixed at 128 bits. Larger keys may be supported in the future, but this usage is currently unspecified.

The counter mode uses a synchronized crypto-counter that is common to the OLT and all ONUs.
The structure of this crypto-counter is as follows. The counter is 46 bits wide. The least significant 16 bits are the intra-frame counter, and the most significant 30 bits are the inter-frame counter.
The intra-frame counter is reset to zero at the beginning of the downstream frame (the first byte of the PCBd), and is incremented every four bytes. In the system with 2.488 Gbit/s downstream rate, the intra-frame counter runs from 0 to 9719.

The inter-frame counter is the same as the super-frame counter passed in the Ident field in the PCBd. The ONU implements a synchronized local counter and therefore has resilience to errors in this field.

The blocks of random cipher are aligned to the beginning of the datagram payloads.
Only the GEM frame/fragment payload is encrypted. The GEM header is not encrypted. Since the fragments need not be an integral number of code blocks, the last data block (1 to 16 bytes in length) is XORed with the most significant portion of the last AES cipher block (16 bytes in length). The excess portion of the last cipher block is discarded.

Note that the crypto-counter is aligned with the GTC downstream frame, but the AES cipher blocks are aligned to the data payloads. The relationship of these two sequences is illustrated in Figure 12-1. When a datagram is sent at the OLT or received at the ONU, the location of the first byte of its header is noted. The value of the crypto-counter at that byte position is used as the starting value of the cipher block counter for that datagram. For subsequent cipher blocks in that datagram, the counter is incremented by 1 for each block. This arrangement assures that the same value of counter is never used more than once.

The 46-bit block counter value drives the 128-bit input of the AES algorithm in the following way.
The 46 bits are duplicated 3 times, producing a 138-bit sequence. The 10 most significant bits are then discarded. The resulting 128-bit number is then encrypted with the AES algorithm, producing 128 bits of random cipher, which is then XORed with the user payload data.

Note that the downstream encryption processing step is applied before FEC. However, the crypto-counter is derived from the frame as-transmitted, so the crypto-counter continues to run through the FEC parity bytes. The scrambling processing step is applied last.

12.3 Key exchange and switch-over

We presume that the OLT and ONU have already configured a Port-ID for encrypted behaviour, and that they have established a key to use. Both the ONU and OLT store the key material in their active_key_registers, and it is this register that the encryption algorithm uses.
The key exchange is initiated by the OLT. The OLT does so by sending the Request_Key message in the PLOAM channel. The ONU responds by generating, storing and sending the key. The ONU stores the new key in the shadow_key_register. The ONU should generate a cryptographically unpredictable key. For guidance in achieving this, see [FIPS 140-2]. Because the PLOAM message is limited in length, the key is sent in two pieces, using the fragmentation field to indicate which part of the key is being sent. Both parts of the key are sent three times for extra redundancy. All ONU transmissions of a particular key have the same value of Key_Index, so that the OLT can definitively confirm that all transmissions are from the same key. The Key_Index is incremented for each key that the ONU generates upon request from the OLT.

If the OLT is unsuccessful in receiving either part of the key all three times it is transmitted, then the OLT will ask the ONU to generate another key by issuing a new Request_Key message. If the key transmission fails three times, then the OLT should declare a loss of key synchronization (LOKi) condition and deactivate the ONU.

Once the OLT successfully receives the key, it stores the validated key in its shadow_key_register.
Now the system is prepared for key switch-over. The OLT chooses a frame number in the future to be the first frame to use the new key. It transmits the super-frame number of this frame to the ONU using the Key_Switching_Time message. This message is sent three times, and the ONU need only receive one correct copy to know the time to switch.

The Key_Switching_Time message requires an acknowledgment by the ONU. If, after three message loss of acknowledgment LOAi condition and deactivate the ONU.
At the beginning of the chosen frame, the OLT will copy the contents of the shadow_key_register into the active_key_register, and the ONU will copy its shadow_key_register into the active_key_register. In this way, both the OLT and ONU begin using the new key at precisely the same frame boundary for any new PDUs (frames) that they exchange.
Note that the AES algorithm requires the generation of a series of round keys based on a single key.
This key scheduling operation takes time, and so it must be done in anticipation of the key switch.
At the moment the key_switch bit is changed, both OLT and ONU must be ready to use the new key.

In some rare cases, an ONU may experience an intermittent LOS/LOF condition that interferes with a scheduled key switch. To ensure graceful recovery in such cases, it is recommended that the OLT restart the key exchange and switch-over procedure with an ONU that has been transitioned from the POPUP state (O6) to the Operation state (O5) immediately upon issuing a directed POPUP message to that ONU."
Titre: Chiffrement du Gpon
Posté par: krtman le 20 mai 2013 à 14:08:42
Pour résumer,

L'UIT a considérait que seul la protection du Downstream était importante du fait qu'il broadcast (niveau 1) vers tous les ONU. Il a jugé que les autres attaques plus exotiques ne sont pas a considérer comme importantes, car elles nécessitent des ressources plus importantes. Il a considéré que du fait de sa nature hautement directionnelle, un ONU ne pouvant pas observer le trafic d'un autre ONU. Cela autorisait l’envoie de clés en claire sur l'upstream. Il évoque bien la menace que représente la pose d'un TAP, mais ils ne considère pas ça comme réaliste du fait que cela doit être fait dans un lieu publique. Par contre ils ne disent pas explicitement si l'Upstream est chiffré.

L’algorithme de cryptage symétrique utilisé et l'AES sur des blocs de 128 bits, avec des clés de taille 128, 192 ou 256 bits. Avec un chiffrement par flot. La norme prévoit quand même la possibilité que l'AES soit un jour cassé, et qu'il puisse être remplacé par un autre algorithme.

Pour l'échange de clés, pas d'algorithme asymétrique, qui aurait permit de protéger l'échange d'une clé de session. La clé est envoyée en claire a l'OLT. Elle est générée aléatoirement par l'ONT, et peut toutefois être changée périodiquement et automatiquement.

Le provisionning de l'ONT peut être réalisé manuellement ou automatiquement grâce a la couche PLOAM. Le mot de passe entré par le technicien évoqué plus haut est a mon avis le mot de passe d'administration de l'ONT et ou de provisionning PLOAM.

Bref il ne reste plus que 802.1x/MACSec ou PPP pour assurer un peut de sécurité, si tant est que les OLT/LNS le supportent.
Titre: Chiffrement du Gpon
Posté par: corrector le 25 février 2016 à 15:36:35
par flot?