Mettre en œuvre la sécurité via le chiffrement (à la fois des données du plan de contrôle (RRC) et des données du plan utilisateur) et la protection de l’intégrité (pour les données du plan de contrôle (RRC) uniquement), c’est la responsabilité de la couche PDCP. . Un compteur PDU de données PDCP (appelé COUNT dans les spécifications LTE) est utilisé comme entrée pour la sécurité des algorithmes. la valeur COUNT est incrémentée pour chaque donnée PDCP PDU lors d’une connexion RRC, a une longueur de 32 bits, pour permettre un temps acceptable pour la connexion RRC.
Lors d’une connexion RRC, le décompte est maintenu à la fois par l’UE et l’eNodeB en comptant chaque PDU de données PDCP transmises/reçues. Pour garantir la robustesse contre la perte de paquets, chaque donnée PDU PDCP protégée comprend un numéro de séquence PDCP (SN) qui correspond aux bits les moins significatifs du décompte. Ainsi, si un ou plusieurs paquets sont perdus, la valeur de comptage correcte d’un nouveau paquet peut être déterminée à l’aide du SN PDCP. Cela signifie que la valeur du compte est associée au prochain compte le plus élevé auquel les bits les moins significatifs correspondent à la valeur du PDCP SN.
Une perte de synchronisation de la valeur de comptage entre l’équipement utilisateur et l’eNodeB peut alors survenir si un nombre de paquets correspondant au SN maximum est perdu consécutivement. En principe, la probabilité que ce type de perte de synchronisation se produise peut être minimisée en augmentant la longueur du SN, même lors de la mesure de la transmission de la valeur de comptage dans chaque ensemble de données PDCP PDU. Cependant, cela entraînera une forte surcharge, et donc seuls les bits les moins significatifs sont utilisés car le SN, la longueur réelle du SN dépend de la configuration et du type de PDU.
Cette utilisation d’un compteur est conçue pour protéger contre un type d’attaque connu sous le nom d’attaque par rejeu où l’attaquant tente d’intercepter un paquet qui a été précédemment calculé à l’aide du COUNT offre une protection contre attaques ciblant la dérivation de modèles et la clé de chiffrement utilisée en comparant des modèles successifs. En raison de l’utilisation de la valeur COUNT, même si le même paquet est transmis deux fois, le modèle de chiffrement sera complètement décorrélé entre les deux transmissions, évitant ainsi d’éventuelles failles de sécurité.
La protection de l’intégrité est effectuée en ajoutant un champ connu sous le nom de Code d’authentification de message pour l’intégrité (MAC-I) pour chaque message RRC. Ce code est basé sur les clés dérivées de la couche d’accès (AS), l’ID du message, le support radio dans la direction (liaison montante ou descendante, c’est-à-dire) et la valeur COUNT.
Si la vérification d’intégrité échoue, le message est rejeté et l’échec de la vérification d’intégrité est indiqué pour la couche RRC, de sorte que la procédure de connexion RRC peut être effectuée. Le chiffrement est réalisé en effectuant une opération XOR avec le message et le flux de chiffrement, qui est généré par l’algorithme de chiffrement sur la base des clés dérivées AS, de la direction d’identité du support radio (c’est-à-dire, liaison montante ou liaison descendante) et de la valeur COUNT.< /p>
Le cryptage peut être appliqué à la PDU de données PDCP. Les PDU de contrôle PDCP (tels que les commentaires ROHC ou les rapports sur l’état de PPPC) ne sont ni cryptés ni protégés en intégrité. Sauf pour les retransmissions identiques, la même valeur COUNT ne peut pas être utilisée plusieurs fois pour la sécurité des clés. ENodeB est responsable d’empêcher de recompter la même combinaison de clé basée sur l’identité du porteur radio et d’algorithme AS. Pour éviter une telle réutilisation, eNodeB peut, par exemple, utiliser différentes identités de porteur radio portant successivement des unités, déclencher une cellule ou déclencher une transition d’état de l’UE connecté au repos et de nouveau connecté.