Auteur Sujet: Chiffrement du Gpon  (Lu 36701 fois)

0 Membres et 1 Invité sur ce sujet

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
Chiffrement du Gpon
« Réponse #60 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.

corrector

  • Invité
Chiffrement du Gpon
« Réponse #61 le: 01 mai 2013 à 21:27:13 »
Quelle est l'autorité de certification? Le constructeur?

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
Chiffrement du Gpon
« Réponse #62 le: 01 mai 2013 à 21:57:57 »
Par exemple.

corrector

  • Invité
Chiffrement du Gpon
« Réponse #63 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?

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 481
  • Malissard (26)
Chiffrement du Gpon
« Réponse #64 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


Bensay

  • Technicien Orange ADSL / FTTH / MIC
  • Abonné Orange Fibre
  • *
  • Messages: 686
  • Val D'oise
Chiffrement du Gpon
« Réponse #65 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

Nico

  • Modérateur
  • *
  • Messages: 44 447
  • FTTH 1000/500 sur Paris 15ème (75)
    • @_GaLaK_
Chiffrement du Gpon
« Réponse #66 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.

Bensay

  • Technicien Orange ADSL / FTTH / MIC
  • Abonné Orange Fibre
  • *
  • Messages: 686
  • Val D'oise
Chiffrement du Gpon
« Réponse #67 le: 02 mai 2013 à 07:39:41 »
SFR à t'il 2 constructeurs différents D'OLT ou un unique?
Ceci expliquerais cela.
Bensay

Nico

  • Modérateur
  • *
  • Messages: 44 447
  • FTTH 1000/500 sur Paris 15ème (75)
    • @_GaLaK_
Chiffrement du Gpon
« Réponse #68 le: 02 mai 2013 à 08:02:14 »
A ma connaissance (ALU et HW), cf. ce que j'ai écrit :

deux constructeurs d'OLT

krtman

  • Expert
  • Abonné Free adsl
  • *
  • Messages: 141
Chiffrement du Gpon
« Réponse #69 le: 20 mai 2013 à 12:39:32 »
Voila ce que dit l'ITU sur la sécurité du GPON :

ITU G.984.4 :

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 :

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."

krtman

  • Expert
  • Abonné Free adsl
  • *
  • Messages: 141
Chiffrement du Gpon
« Réponse #70 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.
« Modifié: 20 mai 2013 à 14:51:42 par krtman »

corrector

  • Invité
Chiffrement du Gpon
« Réponse #71 le: 25 février 2016 à 15:36:35 »
par flot?