Wiki du LAMA (UMR 5127) - Contributions [fr]

Projets étudiants cryptographie et sécurité/Treboux jerome Securite Bluetooth 4X

2016-03-20T23:19:40Z

JeromeTreboux :

'''
== La sécurité du bluetooth 4.X ==
'''

'''Introduction'''

Le bluetooth est moyen de communication a faible portée ( 10-50m), sur la bande des 2,4GHz ( comme le wifi et les fours a micro-ondes) et offrant un débit de 720Kbps ( pour la version 1) a 3Mbps ( pour les version 2 et plus).
On l'utilise surtout pour des services ou des périphérique locaux ( imprimante, claviers, souris, …)
La faible portée rend la consommation énergétique peu importante, ce qui permet de l'utilsier sur la plupart des appareils portables ( téléphones, casque, micro, …).

Pour ce qui est de la sécurité, dans les version antérieur a 4.0, on avait juste 3 modes de protection :
- Pour ce qui est du 1er mode : tout est ouvert et ne protège pas l'équipement, il est visible par tous et accepte la connexion de tous.
- Pour le 2nd mode : Une connexion est obligatoire, et les services sont protégés ou pas selon les choix, il existe plusieurs niveaux de protection pour les services, comme ce qui est expliqué ci dessous.
- Pour le 3ème mode : Tous les services sont obligatoirement protégés.

pour ce qui est de la sécurité des services , il y a 3 niveaux de protection :

- Le niveau 1 qui nécessitent une autorisation et une authentification ( l'autorisation est un niveau de confiance (trust) que seul un administrateur peut avoir ) et l'authentification est le code pin a 4 chiffre qu'on devait écrire quand on voulait s'échanger des fichiers de mobile a mobile.
- Le niveau 2 demande seulement une authentification.
- Et avec le niveau 3 , le service n'a aucune protection.

Voici pour ce qui était fait dans les version antérieur a 4.0 en terme de sécurité.

'''La version 4.0'''

La version 4.0 est le est le Bluetooth Low Energy ( écrit LE, dans la suite de la page), qui introduit : - Une baisse de consommation ainsi qu'un mode de sommeil qui met en pause l'appareil Bluetooth jusqu’à qu'un signal de réveil.
- Une volonté d'amélioration de la sécurité car le Bluetooth était considéré comme facilement attaquable avec les attaques Man In The Middle et beaucoup d'autre ce qui était un problème.

Cette volonté se verra avec la version 4.2 ou la sécurité a été très renforcé

'''La sécurité de la version 4.2'''

Pour éviter les attaques les plus courante, il suffit de crypter le message de manière a que seul le destinataire qui a la clé de déchiffrement pourra comprendre.

Donc pour cela, il faut s'échanger les clés de manière a que si il y a une personne qui écoute les échanges elle ne puisse pas les avoir non plus.
Pour cela, le Bluetooth LE utilise un algorithme appelé « Elliptic Curve Diffie-Hellman » écrit ECDH dans la suite.

[[Fichier:etape.png]]

En plus détaillé, le maître (initiator) , va recevoir une demande de connexion par l'esclave ( responder) , cela peut être aussi l'inverse, mais on va voir sur le premier cas.

Après avoir établie une connexion non cryptée et échanger la courbe écliptique <math>E(a,b,p)</math>, c'est à dire <math>y² = x³ + ax + b mod p</math> , l'esclave va faire une « sécurity_request » pour déterminer le niveau de sécurité de la futur connexion cryptée et les services qui lui sera ouvert dépendra de son niveau de sécurité.

Durant le reste de la ''phase 1'', le maitre et l'esclave vont s'échanger des données, la capacité d'interaction entrée/sortie que veut l'esclave, si l'utilisateur veut une protection contre « Man-In-The-Middle », la taille maximum de clé, … .

Durant la ''phase 2'', il vont commencer pas se choisir une « Temporary Key (TK) » en fonction des des données échangés plus tot.
Cette valeur est un point P sur la courbe ou : « <math>nP = P + P + ... P</math> (n fois) où le « + » correspond à la somme de 2 points définie par le symétrique du troisième point d'intersection de la droite définie par les 2 points originaux avec la courbe elliptique. Dans le cas où les deux points à ajouter sont identiques, on considère que la droite qui les joint est la tangente à la courbe elliptique passant par l'un d'entre eux. Un tel point est rationnel. »

{| class="wikitable alternance centre" style="text-align:center;"
|+ Tableau des méthode d'apairage, la clé qui en sera créer, et pour qulle raison choisir la méthode
|-
! scope="col" | Méthode d'appairage
! scope="col" | Temporary Key (TK)
! scope="col" | Protection contre MITM
! scope="col" | Notes
|-
| Just Works
| 0 (zero)
| NON
| Pas d'authentification
|-
| Passkey Entry
| 0 ... 999999 (six nombre decimal) Le reste de la clé est rempli de zéro.
| OUI
| Authentifier et permet certaines fonctionnalité basique
|-
| Out Of Band
| Une clé de 128bits
| OUI
| Authentifier
|-
|}

Pour un clé de 128bits, on utilise une courbe sur <math>F_{q}</math> , où <math>q\simeq 2^{256}</math>.

Après que la TK ait été créé , cela va être au tour de la « Short Temporary Key (STK) » qui va être généré après un certain nombre d'échange décrit ci dessous.

- Tout d'abord chacun de leur coté ils vont généré un nombre aléatoire de 128 bit ( Maître :« Mrand », Esclave : « Srand »).

- Ensuite chacun de leur coté ils vont calculé « Mconfirm » et « Sconfirm » qui est le résultat d'une fonction qui a comme paramètre la TK, leur nombre aléatoire respectif , et des données échangé plus tôt (adresse, type d'adresse, …).

- Une fois calculé, le Maître va envoyé « Mconfirm », une fois reçu, l'esclave va lui envoyé « Sconfirm », qui va lui répondre en lui renvoyant « Mrand », L'esclave va donc vérifier si « Mconfirm » correspond avec la fonction et les même paramètres (dont « Mrand » qu'il vient de recevoir). Si cela correspond, c'est bien la même personne, il lui envoit a son tour « Srand », sinon la communication est coupé.
Le maitres fait pareil une fois qu'il a reçus « Srand ».

- Une fois qu'ils ont tout les deux vérifier si cela corespondait, ils génèrent tous les deux STK qui est une fonction entre TK, Srand et Mrand.

Ils commence ensuite une conversation crypté en utilisant STK comme clé.

Pour ce qui est de la ''phase 3'', de manière cryptés ils vont s'échanger un certain nombre de clé dont la « Long Temporary Key (LTK)» qui va servir a crypté les communication dés que cette échange de clé sera terminé.

'''Sources'''

[[https://community.freescale.com/thread/332191]]
[[http://blog.bluetooth.com/everything-you-always-wanted-to-know-about-bluetooth-security-in-bluetooth-4-2/]]

Projets étudiants cryptographie et sécurité/Treboux jerome Securite Bluetooth 4X

2016-03-20T23:18:44Z

JeromeTreboux :

'''
== La sécurité du bluetooth 4.X ==
'''

'''Introduction'''

Le bluetooth est moyen de communication a faible portée ( 10-50m), sur la bande des 2,4GHz ( comme le wifi et les fours a micro-ondes) et offrant un débit de 720Kbps ( pour la version 1) a 3Mbps ( pour les version 2 et plus).
On l'utilise surtout pour des services ou des périphérique locaux ( imprimante, claviers, souris, …)
La faible portée rend la consommation énergétique peu importante, ce qui permet de l'utilsier sur la plupart des appareils portables ( téléphones, casque, micro, …)

Pour ce qui est de la sécurité, dans les version antérieur a 4.0, on avait juste 3 modes de protection :
- Pour ce qui est du 1er mode : tout est ouvert et ne protège pas l'équipement, il est visible par tous et accepte la connexion de tous
- Pour le 2nd mode : Une connexion est obligatoire, et les services sont protégés ou pas selon les choix, il existe plusieurs niveaux de protection pour les services, comme ce qui est expliqué ci dessous.
- Pour le 3ème mode : Tous les services sont obligatoirement protégés

pour ce qui est de la sécurité des services , il y a 3 niveaux de protection :

- Le niveau 1 qui nécessitent une autorisation et une authentification ( l'autorisation est un niveau de confiance (trust) que seul un administrateur peut avoir ) et l'authentification est le code pin a 4 chiffre qu'on devait écrire quand on voulait s'échanger des fichiers de mobile a mobile.
- Le niveau 2 demande seulement une authentification
- Et avec le niveau 3 , le service n'a aucune protection.

Voici pour ce qui était fait dans les version antérieur a 4.0 en terme de sécurité

'''La version 4.0'''

La version 4.0 est le est le Bluetooth Low Energy ( écrit LE, dans la suite de la page), qui introduit : - Une baisse de consommation ainsi qu'un mode de sommeil qui met en pause l'appareil Bluetooth jusqu’à qu'un signal de réveil.
- Une volonté d'amélioration de la sécurité car le Bluetooth était considéré comme facilement attaquable avec les attaques Man In The Middle et beaucoup d'autre ce qui était un problème.

Cette volonté se verra avec la version 4.2 ou la sécurité a été très renforcé

'''La sécurité de la version 4.2'''

Pour éviter les attaques les plus courante, il suffit de crypter le message de manière a que seul le destinataire qui a la clé de déchiffrement pourra comprendre.

Donc pour cela, il faut s'échanger les clés de manière a que si il y a une personne qui écoute les échanges elle ne puisse pas les avoir non plus.
Pour cela, le Bluetooth LE utilise un algorithme appelé « Elliptic Curve Diffie-Hellman » écrit ECDH dans la suite.

[[Fichier:etape.png]]

En plus détaillé, le maître (initiator) , va recevoir une demande de connexion par l'esclave ( responder) , cela peut être aussi l'inverse, mais on va voir sur le premier cas.

Après avoir établie une connexion non cryptée et échanger la courbe écliptique <math>E(a,b,p)</math>, c'est à dire <math>y² = x³ + ax + b mod p</math> , l'esclave va faire une « sécurity_request » pour déterminer le niveau de sécurité de la futur connexion cryptée et les services qui lui sera ouvert dépendra de son niveau de sécurité.

Durant le reste de la ''phase 1'', le maitre et l'esclave vont s'échanger des données, la capacité d'interaction entrée/sortie que veut l'esclave, si l'utilisateur veut une protection contre « Man-In-The-Middle », la taille maximum de clé, …

Durant la ''phase 2'', il vont commencer pas se choisir une « Temporary Key (TK) » en fonction des des données échangés plus tot.
Cette valeur est un point P sur la courbe ou : « <math>nP = P + P + ... P</math> (n fois) où le « + » correspond à la somme de 2 points définie par le symétrique du troisième point d'intersection de la droite définie par les 2 points originaux avec la courbe elliptique. Dans le cas où les deux points à ajouter sont identiques, on considère que la droite qui les joint est la tangente à la courbe elliptique passant par l'un d'entre eux. Un tel point est rationnel. »

{| class="wikitable alternance centre" style="text-align:center;"
|+ Tableau des méthode d'apairage, la clé qui en sera créer, et pour qulle raison choisir la méthode
|-
! scope="col" | Méthode d'appairage
! scope="col" | Temporary Key (TK)
! scope="col" | Protection contre MITM
! scope="col" | Notes
|-
| Just Works
| 0 (zero)
| NON
| Pas d'authentification
|-
| Passkey Entry
| 0 ... 999999 (six nombre decimal) Le reste de la clé est rempli de zéro.
| OUI
| Authentifier et permet certaines fonctionnalité basique
|-
| Out Of Band
| Une clé de 128bits
| OUI
| Authentifier
|-
|}

Pour un clé de 128bits, on utilise une courbe sur <math>F_{q}</math> , où <math>q\simeq 2^{256}</math>.

Après que la TK ait été créé , cela va être au tour de la « Short Temporary Key (STK) » qui va être généré après un certain nombre d'échange décrit ci dessous.

- Tout d'abord chacun de leur coté ils vont généré un nombre aléatoire de 128 bit ( Maître :« Mrand », Esclave : « Srand »)

- Ensuite chacun de leur coté ils vont calculé « Mconfirm » et « Sconfirm » qui est le résultat d'une fonction qui a comme paramètre la TK, leur nombre aléatoire respectif , et des données échangé plus tôt (adresse, type d'adresse, …)

- Une fois calculé, le Maître va envoyé « Mconfirm », une fois reçu, l'esclave va lui envoyé « Sconfirm », qui va lui répondre en lui renvoyant « Mrand », L'esclave va donc vérifier si « Mconfirm » correspond avec la fonction et les même paramètres (dont « Mrand » qu'il vient de recevoir). Si cela correspond, c'est bien la même personne, il lui envoit a son tour « Srand », sinon la communication est coupé.
Le maitres fait pareil une fois qu'il a reçus « Srand »

- Une fois qu'ils ont tout les deux vérifier si cela corespondait, ils génèrent tous les deux STK qui est une fonction entre TK, Srand et Mrand

Ils commence ensuite une conversation crypté en utilisant STK comme clé.

Pour ce qui est de la ''phase 3'', de manière cryptés ils vont s'échanger un certain nombre de clé dont la « Long Temporary Key (LTK)» qui va servir a crypté les communication dés que cette échange de clé sera terminé.

'''Sources'''

[[https://community.freescale.com/thread/332191]]
[[http://blog.bluetooth.com/everything-you-always-wanted-to-know-about-bluetooth-security-in-bluetooth-4-2/]]

Projets étudiants cryptographie et sécurité/Treboux jerome Securite Bluetooth 4X

2016-03-20T23:18:18Z

JeromeTreboux :

'''
== La sécurité du bluetooth 4.X ==
'''

'''Introduction'''

Le bluetooth est moyen de communication a faible portée ( 10-50m), sur la bande des 2,4GHz ( comme le wifi et les fours a micro-ondes) et offrant un débit de 720Kbps ( pour la version 1) a 3Mbps ( pour les version 2 et plus).
On l'utilise surtout pour des services ou des périphérique locaux ( imprimante, claviers, souris, …)
La faible portée rend la consommation énergétique peu importante, ce qui permet de l'utilsier sur la plupart des appareils portables ( téléphones, casque, micro, …)

Pour ce qui est de la sécurité, dans les version antérieur a 4.0, on avait juste 3 modes de protection :
- Pour ce qui est du 1er mode : tout est ouvert et ne protège pas l'équipement, il est visible par tous et accepte la connexion de tous
- Pour le 2nd mode : Une connexion est obligatoire, et les services sont protégés ou pas selon les choix, il existe plusieurs niveaux de protection pour les services, comme ce qui est expliqué ci dessous.
- Pour le 3ème mode : Tous les services sont obligatoirement protégés

pour ce qui est de la sécurité des services , il y a 3 niveaux de protection :

- Le niveau 1 qui nécessitent une autorisation et une authentification ( l'autorisation est un niveau de confiance (trust) que seul un administrateur peut avoir ) et l'authentification est le code pin a 4 chiffre qu'on devait écrire quand on voulait s'échanger des fichiers de mobile a mobile.
- Le niveau 2 demande seulement une authentification
- Et avec le niveau 3 , le service n'a aucune protection.

Voici pour ce qui était fait dans les version antérieur a 4.0 en terme de sécurité

'''La version 4.0'''

La version 4.0 est le est le Bluetooth Low Energy ( écrit LE, dans la suite de la page), qui introduit : - Une baisse de consommation ainsi qu'un mode de sommeil qui met en pause l'appareil Bluetooth jusqu’à qu'un signal de réveil.
- Une volonté d'amélioration de la sécurité car le Bluetooth était considéré comme facilement attaquable avec les attaques Man In The Middle et beaucoup d'autre ce qui était un problème.

Cette volonté se verra avec la version 4.2 ou la sécurité a été très renforcé

'''La sécurité de la version 4.2'''

Pour éviter les attaques les plus courante, il suffit de crypter le message de manière a que seul le destinataire qui a la clé de déchiffrement pourra comprendre.

Donc pour cela, il faut s'échanger les clés de manière a que si il y a une personne qui écoute les échanges elle ne puisse pas les avoir non plus.
Pour cela, le Bluetooth LE utilise un algorithme appelé « Elliptic Curve Diffie-Hellman » écrit ECDH dans la suite.

[[Fichier:etape.png]]

En plus détaillé, le maître (initiator) , va recevoir une demande de connexion par l'esclave ( responder) , cela peut être aussi l'inverse, mais on va voir sur le premier cas.

Après avoir établie une connexion non cryptée et échanger la courbe écliptique <math>E(a,b,p)</math>, c'est à dire <math>y² = x³ + ax + b mod p</math> , l'esclave va faire une « sécurity_request » pour déterminer le niveau de sécurité de la futur connexion cryptée et les services qui lui sera ouvert dépendra de son niveau de sécurité.

Durant le reste de la ''phase 1'', le maitre et l'esclave vont s'échanger des données, la capacité d'interaction entrée/sortie que veut l'esclave, si l'utilisateur veut une protection contre « Man-In-The-Middle », la taille maximum de clé, …

Durant la ''phase 2'', il vont commencer pas se choisir une « Temporary Key (TK) » en fonction des des données échangés plus tot.
Cette valeur est un point P sur la courbe ou : « <math>nP = P + p + ... P</math> (n fois) où le « + » correspond à la somme de 2 points définie par le symétrique du troisième point d'intersection de la droite définie par les 2 points originaux avec la courbe elliptique. Dans le cas où les deux points à ajouter sont identiques, on considère que la droite qui les joint est la tangente à la courbe elliptique passant par l'un d'entre eux. Un tel point est rationnel. »

{| class="wikitable alternance centre" style="text-align:center;"
|+ Tableau des méthode d'apairage, la clé qui en sera créer, et pour qulle raison choisir la méthode
|-
! scope="col" | Méthode d'appairage
! scope="col" | Temporary Key (TK)
! scope="col" | Protection contre MITM
! scope="col" | Notes
|-
| Just Works
| 0 (zero)
| NON
| Pas d'authentification
|-
| Passkey Entry
| 0 ... 999999 (six nombre decimal) Le reste de la clé est rempli de zéro.
| OUI
| Authentifier et permet certaines fonctionnalité basique
|-
| Out Of Band
| Une clé de 128bits
| OUI
| Authentifier
|-
|}

Pour un clé de 128bits, on utilise une courbe sur <math>F_{q}</math> , où <math>q\simeq 2^{256}</math>.

Après que la TK ait été créé , cela va être au tour de la « Short Temporary Key (STK) » qui va être généré après un certain nombre d'échange décrit ci dessous.

- Tout d'abord chacun de leur coté ils vont généré un nombre aléatoire de 128 bit ( Maître :« Mrand », Esclave : « Srand »)

- Ensuite chacun de leur coté ils vont calculé « Mconfirm » et « Sconfirm » qui est le résultat d'une fonction qui a comme paramètre la TK, leur nombre aléatoire respectif , et des données échangé plus tôt (adresse, type d'adresse, …)

- Une fois calculé, le Maître va envoyé « Mconfirm », une fois reçu, l'esclave va lui envoyé « Sconfirm », qui va lui répondre en lui renvoyant « Mrand », L'esclave va donc vérifier si « Mconfirm » correspond avec la fonction et les même paramètres (dont « Mrand » qu'il vient de recevoir). Si cela correspond, c'est bien la même personne, il lui envoit a son tour « Srand », sinon la communication est coupé.
Le maitres fait pareil une fois qu'il a reçus « Srand »

- Une fois qu'ils ont tout les deux vérifier si cela corespondait, ils génèrent tous les deux STK qui est une fonction entre TK, Srand et Mrand

Ils commence ensuite une conversation crypté en utilisant STK comme clé.

Pour ce qui est de la ''phase 3'', de manière cryptés ils vont s'échanger un certain nombre de clé dont la « Long Temporary Key (LTK)» qui va servir a crypté les communication dés que cette échange de clé sera terminé.

'''Sources'''

[[https://community.freescale.com/thread/332191]]
[[http://blog.bluetooth.com/everything-you-always-wanted-to-know-about-bluetooth-security-in-bluetooth-4-2/]]

Projets étudiants cryptographie et sécurité/Treboux jerome Securite Bluetooth 4X

2016-03-20T23:07:42Z

JeromeTreboux :

'''
== La sécurité du bluetooth 4.X ==
'''

'''Introduction'''

Le bluetooth est moyen de communication a faible portée ( 10-50m), sur la bande des 2,4GHz ( comme le wifi et les fours a micro-ondes) et offrant un débit de 720Kbps ( pour la version 1) a 3Mbps ( pour les version 2 et plus).
On l'utilise surtout pour des services ou des périphérique locaux ( imprimante, claviers, souris, …)
La faible portée rend la consommation énergétique peu importante, ce qui permet de l'utilsier sur la plupart des appareils portables ( téléphones, casque, micro, …)

Pour ce qui est de la sécurité, dans les version antérieur a 4.0, on avait juste 3 modes de protection :
- Pour ce qui est du 1er mode : tout est ouvert et ne protège pas l'équipement, il est visible par tous et accepte la connexion de tous
- Pour le 2nd mode : Une connexion est obligatoire, et les services sont protégés ou pas selon les choix, il existe plusieurs niveaux de protection pour les services, comme ce qui est expliqué ci dessous.
- Pour le 3ème mode : Tous les services sont obligatoirement protégés

pour ce qui est de la sécurité des services , il y a 3 niveaux de protection :

- Le niveau 1 qui nécessitent une autorisation et une authentification ( l'autorisation est un niveau de confiance (trust) que seul un administrateur peut avoir ) et l'authentification est le code pin a 4 chiffre qu'on devait écrire quand on voulait s'échanger des fichiers de mobile a mobile.
- Le niveau 2 demande seulement une authentification
- Et avec le niveau 3 , le service n'a aucune protection.

Voici pour ce qui était fait dans les version antérieur a 4.0 en terme de sécurité

'''La version 4.0'''

La version 4.0 est le est le Bluetooth Low Energy ( écrit LE, dans la suite de la page), qui introduit : - Une baisse de consommation ainsi qu'un mode de sommeil qui met en pause l'appareil Bluetooth jusqu’à qu'un signal de réveil.
- Une volonté d'amélioration de la sécurité car le Bluetooth était considéré comme facilement attaquable avec les attaques Man In The Middle et beaucoup d'autre ce qui était un problème.

Cette volonté se verra avec la version 4.2 ou la sécurité a été très renforcé

'''La sécurité de la version 4.2'''

Pour éviter les attaques les plus courante, il suffit de crypter le message de manière a que seul le destinataire qui a la clé de déchiffrement pourra comprendre.

Donc pour cela, il faut s'échanger les clés de manière a que si il y a une personne qui écoute les échanges elle ne puisse pas les avoir non plus.
Pour cela, le Bluetooth LE utilise un algorithme appelé « Elliptic Curve Diffie-Hellman » écrit ECDH dans la suite.

[[Fichier:etape.png]]

En plus détaillé, le maître (initiator) , va recevoir une demande de connexion par l'esclave ( responder) , cela peut être aussi l'inverse, mais on va voir sur le premier cas.

Après avoir établie une connexion non cryptée et échanger la courbe écliptique <math>E(a,b,p)</math>, c'est à dire <math>y² = x³ + ax + b mod p</math> , l'esclave va faire une « sécurity_request » pour déterminer le niveau de sécurité de la futur connexion cryptée et les services qui lui sera ouvert dépendra de son niveau de sécurité.

Durant le reste de la phase 1, le maitre et l'esclave vont s'échanger des données, la capacité d'interaction entrée/sortie que veut l'esclave, si l'utilisateur veut une protection contre « Man-In-The-Middle », la taille maximum de clé, …

Durant la phase 2, il vont commencer pas se choisir une « Temporary Key (TK) » en fonction des des données échangés plus tot.
Cette valeur est un point P sur la courbe ou : « <math>nP = P + p + ... P</math> (n fois) où le « + » correspond à la somme de 2 points définie par le symétrique du troisième point d'intersection de la droite définie par les 2 points originaux avec la courbe elliptique. Dans le cas où les deux points à ajouter sont identiques, on considère que la droite qui les joint est la tangente à la courbe elliptique passant par l'un d'entre eux. Un tel point est rationnel. »

{| class="wikitable alternance centre" style="text-align:center;"
|+ Tableau des méthode d'apairage, la clé qui en sera créer, et pour qulle raison choisir la méthode
|-
! scope="col" | Méthode d'appairage
! scope="col" | Temporary Key (TK)
! scope="col" | Protection contre MITM
! scope="col" | Notes
|-
| Just Works
| 0 (zero)
| NON
| Pas d'authentification
|-
| Passkey Entry
| 0 ... 999999 (six nombre decimal) Le reste de la clé est rempli de zéro.
| OUI
| Authentifier et permet certaines fonctionnalité basique
|-
| Out Of Band
| Une clé de 128bits
| OUI
| Authentifier
|-
|}

Pour un clé de 128bits, on utilise une courbe sur , où .
Après que la TK ait été créé , cela va être au tour de la « Short Temporary Key (STK) » qui va être généré après un certain nombre d'échange décrit ci dessous.

- Tout d'abord chacun de leur coté ils vont généré un nombre aléatoire de 128 bit ( Maître :« Mrand », Esclave : « Srand »)

- Ensuite chacun de leur coté ils vont calculé « Mconfirm » et « Sconfirm » qui est le résultat d'une fonction qui a comme paramètre la TK, leur nombre aléatoire respectif , et des données échangé plus tôt (adresse, type d'adresse, …)

- Une fois calculé, le Maître va envoyé « Mconfirm », une fois reçu, l'esclave va lui envoyé « Sconfirm », qui va lui répondre en lui renvoyant « Mrand », L'esclave va donc vérifier si « Mconfirm » correspond avec la fonction et les même paramètres (dont « Mrand » qu'il vient de recevoir). Si cela correspond, c'est bien la même personne, il lui envoit a son tour « Srand », sinon la communication est coupé.
Le maitres fait pareil une fois qu'il a reçus « Srand »

- Une fois qu'ils ont tout les deux vérifier si cela corespondait, ils génèrent tous les deux STK qui est une fonction entre TK, Srand et Mrand

Ils commence ensuite une conversation crypté en utilisant STK comme clé.

Pour ce qui est de la phase 3, de manière cryptés ils vont s'échanger un certain nombre de clé dont la « Long Temporary Key (LTK)» qui va servir a crypté les communication dés que cette échange de clé sera terminé.

'''Sources'''

[[https://community.freescale.com/thread/332191]]
[[http://blog.bluetooth.com/everything-you-always-wanted-to-know-about-bluetooth-security-in-bluetooth-4-2/]]

Projets étudiants cryptographie et sécurité/Treboux jerome Securite Bluetooth 4X

2016-03-20T23:05:41Z

JeromeTreboux :

'''
== La sécurité du bluetooth 4.X ==
'''

'''Introduction'''

Le bluetooth est moyen de communication a faible portée ( 10-50m), sur la bande des 2,4GHz ( comme le wifi et les fours a micro-ondes) et offrant un débit de 720Kbps ( pour la version 1) a 3Mbps ( pour les version 2 et plus).
On l'utilise surtout pour des services ou des périphérique locaux ( imprimante, claviers, souris, …)
La faible portée rend la consommation énergétique peu importante, ce qui permet de l'utilsier sur la plupart des appareils portables ( téléphones, casque, micro, …)

Pour ce qui est de la sécurité, dans les version antérieur a 4.0, on avait juste 3 modes de protection :
- Pour ce qui est du 1er mode : tout est ouvert et ne protège pas l'équipement, il est visible par tous et accepte la connexion de tous
- Pour le 2nd mode : Une connexion est obligatoire, et les services sont protégés ou pas selon les choix, il existe plusieurs niveaux de protection pour les services, comme ce qui est expliqué ci dessous.
- Pour le 3ème mode : Tous les services sont obligatoirement protégés

pour ce qui est de la sécurité des services , il y a 3 niveaux de protection :

- Le niveau 1 qui nécessitent une autorisation et une authentification ( l'autorisation est un niveau de confiance (trust) que seul un administrateur peut avoir ) et l'authentification est le code pin a 4 chiffre qu'on devait écrire quand on voulait s'échanger des fichiers de mobile a mobile.
- Le niveau 2 demande seulement une authentification
- Et avec le niveau 3 , le service n'a aucune protection.

Voici pour ce qui était fait dans les version antérieur a 4.0 en terme de sécurité

'''La version 4.0'''

La version 4.0 est le est le Bluetooth Low Energy ( écrit LE, dans la suite de la page), qui introduit : - Une baisse de consommation ainsi qu'un mode de sommeil qui met en pause l'appareil Bluetooth jusqu’à qu'un signal de réveil.
- Une volonté d'amélioration de la sécurité car le Bluetooth était considéré comme facilement attaquable avec les attaques Man In The Middle et beaucoup d'autre ce qui était un problème.

Cette volonté se verra avec la version 4.2 ou la sécurité a été très renforcé

'''La sécurité de la version 4.2'''

Pour éviter les attaques les plus courante, il suffit de crypter le message de manière a que seul le destinataire qui a la clé de déchiffrement pourra comprendre.

Donc pour cela, il faut s'échanger les clés de manière a que si il y a une personne qui écoute les échanges elle ne puisse pas les avoir non plus.
Pour cela, le Bluetooth LE utilise un algorithme appelé « Elliptic Curve Diffie-Hellman » écrit ECDH dans la suite.

[[Fichier:etape.png]]

En plus détaillé, le maître (initiator) , va recevoir une demande de connexion par l'esclave ( responder) , cela peut être aussi l'inverse, mais on va voir sur le premier cas.

Après avoir établie une connexion non cryptée et échanger la courbe écliptique <math>E(a,b,p)</math>, c'est à dire <math>y² = x³ + ax + b mod p</math> , l'esclave va faire une « sécurity_request » pour déterminer le niveau de sécurité de la futur connexion cryptée et les services qui lui sera ouvert dépendra de son niveau de sécurité.

Durant le reste de la phase 1, le maitre et l'esclave vont s'échanger des données, la capacité d'interaction entrée/sortie que veut l'esclave, si l'utilisateur veut une protection contre « Man-In-The-Middle », la taille maximum de clé, …

Durant la phase 2, il vont commencer pas se choisir une « Temporary Key (TK) » en fonction des des données échangés plus tot.
Cette valeur est un point P sur la courbe ou : « <math>nP = P + p + ... P</math> (n fois) où le « + » correspond à la somme de 2 points définie par le symétrique du troisième point d'intersection de la droite définie par les 2 points originaux avec la courbe elliptique. Dans le cas où les deux points à ajouter sont identiques, on considère que la droite qui les joint est la tangente à la courbe elliptique passant par l'un d'entre eux. Un tel point est rationnel. »

{| class="wikitable alternance centre" style="text-align:center;"
|+ Tableau des méthode d'apairage, la clé qui en sera créer, et pour qulle raison choisir la méthode
|-
! scope="col" | Méthode d'appairage
! scope="col" | Temporary Key (TK)
! scope="col" | Protection contre MITM
! scope="col" | Notes
|-
| Just Works
| 0 (zero)
| NON
| Pas d'authentification
|-
| Passkey Entry
| 0 ... 999999 (six nombre decimal) Le reste de la clé est rempli de zéro.
| OUI
| Authentifier et permet certaines fonctionnalité basique
|-
| Out Of Band
| Une clé de 128bits
| OUI
| Authentifier
|-
|}

Pour un clé de 128bits, on utilise une courbe sur , où .
Après que la TK ait été créé , cela va être au tour de la « Short Temporary Key (STK) » qui va être généré après un certain nombre d'échange décrit ci dessous.

- Tout d'abord chacun de leur coté ils vont généré un nombre aléatoire de 128 bit ( Maître :« Mrand », Esclave : « Srand »)

- Ensuite chacun de leur coté ils vont calculé « Mconfirm » et « Sconfirm » qui est le résultat d'une fonction qui a comme paramètre la TK, leur nombre aléatoire respectif , et des données échangé plus tôt (adresse, type d'adresse, …)

- Une fois calculé, le Maître va envoyé « Mconfirm », une fois reçu, l'esclave va lui envoyé « Sconfirm », qui va lui répondre en lui renvoyant « Mrand », L'esclave va donc vérifier si « Mconfirm » correspond avec la fonction et les même paramètres (dont « Mrand » qu'il vient de recevoir). Si cela correspond, c'est bien la même personne, il lui envoit a son tour « Srand », sinon la communication est coupé.
Le maitres fait pareil une fois qu'il a reçus « Srand »

- Une fois qu'ils ont tout les deux vérifier si cela corespondait, ils génèrent tous les deux STK qui est une fonction entre TK, Srand et Mrand

Ils commence ensuite une conversation crypté en utilisant STK comme clé.

Pour ce qui est de la phase 3, de manière cryptés ils vont s'échanger un certain nombre de clé dont la « Long Temporary Key (LTK)» qui va servir a crypté les communication dés que cette échange de clé sera terminé.

Fichier:Etape.png

2016-03-20T22:40:55Z

JeromeTreboux : Un shéma des phases pour l'echange de clé

Un shéma des phases pour l'echange de clé

Projets étudiants cryptographie et sécurité/Treboux jerome Securite Bluetooth 4X

2016-03-07T18:25:43Z

JeromeTreboux : Page créée avec « Page en fabrication veuillez repasser plus tard, merci __________ || .------.| ... »

Page en fabrication veuillez repasser plus tard, merci

__________
|| .------.|
||/ [|
||| /||
|||\ | [|
_ ________ _ |||.'___| |'---...__
/o)===|________(o\ ||========| ``-..
/ / _.----'\ \ |'=.====.=' ________ \
/ | .-' ----. / | | |____| .'.-------.\ |
\ \ .'_.----._ \ | _\_|____|.'.'_.----._ \\__|
/\ \ .'.' __ `.\ |-_| |____| /.' __ '.\ |
// \ \' / / \ \\|-_|_|____|// / \ \`--'
// \ / .| | | | |____| | | | |
// \ .'.' | \ __ / | | \ __ / |
// /'.' '. .' '. .'
//_____.'-' `-.__.-' `-.__.-'

Projets étudiants cryptographie et sécurité

2016-03-07T18:20:34Z

JeromeTreboux :

= Sécurité informatique =

== Logiciels malveillants ==

# le virus "stuxnet" { N. Challut et T. Chisci }
# Cryptolocker { W. Lecable, M. Genovese }
# Octobre Rouge { REGAZZONI Rudy et LOMBARD Adrien } (ok)
# Virus et antivirus (ok) {EL AZHAR Said}
# Présentation et explication de l'attaque par le virus Stuxnet (ok) {PIRAT Victor et MENDES Etienne}
# Virus et antivirus { Mehdi M. et Christophe M. }
# Virus et Antivirus {L Burnet et Y Bouklinam } [[Projets_%C3%A9tudiants_cryptographie_et_s%C3%A9curit%C3%A9/BouklinamBurnet_Virus_Antivirus]]

== Attaques, exploit ==

# Présentation et explication d'une attaque historique (laquelle ?) { FLEUTIAUX Marc et AGUETTAZ Cédric}
# Tour d'horizon des attaques par Injection SQL. (ok) {MILLER Lucas et VIONNET Jean}
# Attaques sur SSL. (ok) {Ferlay Mathieu et Six Lancelot}
# Le Phreaking, piratage téléphonique (ok) {Rey Myriam}
# IP Spoofing et DNS Spoofing { Alberic Martel & Fabien Dezempte ) [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/ip-dns-spoofing.ppt PPT]
# Les attaques médiatisées sur les systèmes informatiques {Renneville Guybert et Fabrice Noraz}
# Les attaques médiatisées sur les systèmes informatiques : Attaque de Mitnick, Morris Worm, DDOS Mafia Boy, etc <<<< { PIPARO, HUMBERT } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Les_attaques_mediatisees_-_PIPARO_HUMBERT.pdf PDF]
# Attaques par injection de code XSS, parades <<<< { SERRA & ROCHE ) [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Expose_securite_sur_le_XSS_-_Roche_et_Serra.pdf PDF]
# IP Spoofing et DNS Spoofing <<<< { DEMOLIS & JUMEAU )
# "Reset Glitch Hack" Xbox 360 {Joris et Tim}

== Sécurité applicative ==

# Comparaison de différents logiciels de crackage (ok) { AMBLARD Mathieu }
# Construire des bons mots de passe { Liu Siqi }
# Sécurité anti-piratage (ok) {CHEVALIER Daniel et REIGNIER David}

== Sécurité réseaux ==

# La sécurité et les chaines TV cryptées { CINDOLO Giuseppe & NARETTO Benjamin }
# Tunneling TCP/IP via SSH {RAHARISON Laurent & JEAN FRANÇOIS Michael}
# HTTPS et SSL { ASSIER Aymeric et ROLLINGER Claire } (ok)
# DMZ { COLLOMB Camille et LAURENT Corantin } (ok)
# Sécurité des réseaux sans fils (ok) { ZHONG Jie et GONZALEZ Miguel }
# Le principe de VPN et les attaques de VPN (ok) { DU Peng }
# Présentation de quelques attaques informatiques et quelques solutions proposées pour y remédier dans les réseaux P2P (ok) { Lila Zane et Ouhemmi }
# Comment Aircrack trouve les clés WEP des réseaux wifi (ok) { LANOISELIER Aurélien et MARCHANOFF Jérôme}
# Tunneling, sécurisation et piratage (ok). {COLLEN Cyril et LAQUA Johann}
# Securité des réseaux sans fils (ok) {Tounkara Mounina et Philippe Monteiro}
# Les Protocoles de sécurité dans les réseaux WiFi (WEP et WPA) <<<< { Mickaël Wang & Arnaud Villevieille } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/Securite-wifi.pdf PDF]
# Les outils d'analyse de la sécurité des réseaux : renifleur, scanneurs de ports, outils de détection d'intruison { Anis HADJALI & Vlad VESA } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/analyse-securite.pdf PDF]
# L'introduction SSL,SSH { Julien Roche & Yi Wang }
# Secure shell (SSH) : protocole, applications, tunnelling <<<< {BODIN}
# Sécurité des réseaux sans fil : authentification, chiffrement, WEP, WPA =>Bugnard/Berthet
# Sécuriser un réseau : pare-feu, zone démilitarisée, protection des serveurs, adressage local <<<<<< {FOLLIET et VIALA} [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/presentation_VIALA_FOLLIET.pdf PDF]
# IPsec

== Sécurité de l'hôte ==

# La sécurité dans les box de FAI { Charron Thomas & Mesurolle Anthony }
# Failles de sécurité des systèmes informatiques de grandes entreprises (LinkedIn, Apple, Sony, ...) { ARNOULD Mickaël et LEMAIRE Noémie } (ok)
# La virtualisation, facteur de sécurité ou de vulnérabilité (ok) { DIMIER Cédric et CARRIE Antoine }
# Sécurité sous Linux en entreprise { Joël Leroy Ebouele & Barbier Keller }
# Techniques et outils de chiffrements de partitions [Valat Sebastien & Bouleis Romain]
# OpenBSD : aspects sécurité <<<<<< (REVELIN et ERROCHDI) [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/OpenBSD_-_Revelin-Errochdi.pdf PDF]

== Sécurité et web ==

# Google Recaptcha { A. SAYAH, A. EL-HARRAS }
# Le Cloud et la Cryptologie { Capellaro Alexandre & Chabert Cédric }
# Sécurité atypique et empreintes des navigateurs {FONTANA Antonin}
# Injections SQL & faille XSS { GUILLOT Pierre & KRATTINGER Thibaut }
# Nouvelle philosophie de partage de fichiers avec MEGA { WAYNTAL David et DOMINATI Nicolas } (ok)
# La sécurité sur les sites Web (ok) {RABARIJAONA Domoina et BERTHET Vincent}
# Présentation des Honeypots (ok) {Adiche Rafik et Jean-François Michel-Patrique}
# Google Hacking { Julien ARNOUX & Jeremy DEPOIL } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/ghack.pptx PPTX]

== Sécurité des mobiles et informatique ambiante ==

# Sécurité et mobile : nouvelle cible des pirates { GEVET Gwénaël et YANG Yang } (ok)
# Vulnérabilités des smartphones (ok) {Titouan VAN BELLE et Jean-Baptiste PAUMIER}
# L'Informatique Ambiante et La Sécurité:Quel Protocole? (ok) {Marclin LEON et Farid BOUKHEDDAD}
# Vulnérabilité du protocole A5/1 des mobiles GSM. <<<<< {FERNANDES} [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Cryptologie_et_securite_informatique_-_Fernandes.pdf PDF]
# Sécurité GPRS <<<<<< (PEHME et REY) [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Securite_GPRS_-PEHME_REY.pdf PDF]
# Sécurité Bluetooth 4.X ( Treboux Jérome ) [[Projets_étudiants_cryptographie_et_sécurité/Treboux_jerome_Securite_Bluetooth_4X]]

== Politique de sécurité ==

# Sécurité et [http://www.infosafe.fr/Armoirefortedin/Armoirefortedin.htm armoire forte ignifuge] pour les sauvegardes de données
# Fuites de donnée en entreprise (ok) {Tounkara Mounina et Philippe Monteiro}
# PRA le Plan de Reprise d'Activité {Achraf AMEUR}
# La mise en place de la sécurité informatique au niveau national et international : CERTs, sites AntiSPAM

= Cryptographie =

== Génération aléatoire ==

# Principes et techniques de génération de nombres aléatoires {BERTHON Yohann & KELFANI Hugo & REY Anthony}
# Systèmes physiques de génération de nombres aléatoires : principes et avantages. (ok) {Florent Carral et Julie Tacheau}

== Chiffrement symétrique (à clé secrète partagée) ==

# AES { Avet Anthony & Duraz Aurélien }
# IDEA { Caillet François & Di Lisio Anthony } [[Projets_étudiants_cryptographie_et_sécurité/Caillet_DiLisio_IDEA]]

== Chiffrement asymétrique (à clé publique) ==

# PGP et la sécurité de l'information {Cyrille Mortier}

== Signature, certificats ==

# La signature numérique (ok) { DJEDDI Abdelkader }
# Les certificats (PGP, X509) et les infrastructures de gestion de clés

== Empreintes et fonctions de hachage ==

== Cryptanalyse ==

# Le craquage de la cryptographie quantique ? { D. Cauwet, A. Hauguel }
# Calculateurs quantiques et applications en cryptographie { BORCARD Justine et CATHELIN Gaël }
# Vulnérabilité du protocole WEP et de RC4 pour les réseaux WiFi <<<< { PAVLOU, DALLACOSTA } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Presentation_cryptologie_PAVLOU_DALLA_COSTA_512.mov MOV]

== Tatouage, watermarking, biométrie, DRM ==

# La stéganographie { K. Deléglise, Y. Rakotonanahary }
# La stéganographie { Bosviel Thomas & Tolron Sebastien}
# Biométrie { BACART Aurélien et BAH Abdoulaye } (ok)
# Biométrie (ok) { ZANE Bania et MENTDAHI Houda }
# Stéganographie(ok) { PONCET Johan et MARTIN Romain}
# Stéganographie ou les signatures numériques (ok) { TARDY Camille et CASSAGNERES Pierre-André}
# La biométrie, une solution miracle pour l'authentification ? (ok) { FERNANDES PIRES Anthony et GAYET Eric}
# La gestion des DRM {Petithory Thomas & Paccard Charléric}
# Le tatouage d'image et de document (watermarking) <<<< {MAESEELE, CIMINERA } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2007/Watermarking_Ciminera_Maeseele.pdf PDF]
# Watermarking et steganographie { Adrien DETRAZ et Julien CABALLOL } [https://lama.univ-savoie.fr/mediawiki/index.php/Projets_étudiants_cryptographie_et_sécurité/Detraz_Caballol_Watermarking_Steganographie Projets_étudiants_cryptographie_et_sécurité/Caballol-Detraz_Watermarking_Steganographie]

== Cryptographie quantique ==

# Principes de cryptographie quantique (DE ROLAND Céline, LECLAIRE Juliana) [[Projets_%C3%A9tudiants_cryptographie_et_s%C3%A9curit%C3%A9/Leclaire_DeRoland_Crypto_Quantique]]
# Cryptographie quantique: Vulnérabilités ( DCHAR Ahmed, AMJAD Nassif ) [[Projets_étudiants_cryptographie_et_sécurité/Dchar-Amjad_Cryptographie_Quantique_Vulnerabilités]]

= Sécurité, cryptographie dans la société =

== Cryptographie historique ==

# La cryptographie dans l'antiquité { Y. Lombardi, G. Badin }
# La machine de Turing et ses variantes { C. Laignel, P.E. Roux }
# La machine ENIGMA { B. Da Silva, G. Ply }
# L'histoire de la cryptographie (ok) {Costa Jean-Philippe et Morel Julien}
# Evolution de la cryptologie à travers les âges (ok, mais vaste !) { DEBAENE Aurélien et VINCENT Christophe }
# La Machine Enigma (ok) { JULLIAN-DESAYES Jeremy et GARDET Nicolas }

== Cyberguerre ==

# Cryptologie VS NSA { H. Ramamonjy, N.E. Ould Kadi }
# La cyberguerre { COLIN François et APPREDERISSE Benjamin } (ok)
# La cryptographie militaire { GIUNCHI Ryan & CIMINERA Lary }
# La cyberguerre (ok) {MAIRE Cyril et MONTCHAL Justine}
# La cyberguerre (ok) { SOUBEYRAND Martin et ROBART Laetitia }

== Monnaies électroniques ==

# le Bitcoin { H. Helbawi, A. Tang, J. }
# Le cryptosystème Bitcoin { Johanny Clerc-Renaud & Clément Montigny }
# La sécurité des monnaies électroniques {BUISSON Valentin & GENY-DUMONT Rémi}

== Cartes bancaires ==

# La sécurité des cartes bancaires { M. Salvat, Y. Salti }
# Sécurité des cartes bancaires { A. Bigane, F. Way }
# Le paiement par NFC { J. Maurice, S. Zehnder }
# Payement NFC { Montouchet Raphaël & Marois Jeremy }
# La technologie RFID et la sécurité { CHANTREL Thierry & SEZILLE Aurélien }
# La sécurité des cartes bancaires (ok) { DORIEN Christophe et LAPIERRE Rémy }
# Sécurité dans les cartes à puce (ok) { LAGHA Youssef et Nodari }
# 3DSecure { Natalia Lecoeur & Cindy Chiaberto } [http://www.lama.univ-savoie.fr/~lachaud/Cours/INFO913/Prez-2008-2009/3D_Secure.pdf PDF]