VT2020 - Nearby Communications Fiche: Difference between revisions
Robin.Delbos (talk | contribs) (Redirected page to VT2020-Apache Arrow-Fiche) |
No edit summary |
||
(24 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
[[File:logoNearby.jpg|200px|right|thumb|Logo de la plateforme Nearby]] |
|||
#REDIRECT [[VT2020-Apache Arrow-Fiche]] |
|||
Nearby est une plateforme lancée par Google en 2014. Elle est composée de deux APIs, Nearby Connections et Nearby Messages. Ces APIs permettent de faciliter la connexion entre des appareils situés à proximité (par exemple de pouvoir s'envoyer un message sans avoir besoin d'un numéro de téléphone). |
|||
== Description des API == |
|||
Nearby est en réalité constitué de deux APIs : Nearby Connections et Nearby Messages. Elles apportent des services similaires mais avec des caractéristiques différentes. |
|||
[[File:Nearby_connections.jpg|200px|right|thumb|Schéma de l'API Nearby Connections]] |
|||
'''Nearby Connections API''' |
|||
L'API Nearby Connections permet de créer une connexion locale entre des appareils à proximité en temps réel. Par exemple, elle rend possible d'associer des appareils et de s'en servir pour des jeux multijoueurs. La connexion est donc limitée au réseau local : tous les appareils doivent être sur le même réseau Wifi. La communication n'est possible qu'entre des appareils Android. Son principe de fonctionnement ressemble à une architecture Client-Serveur que nous détaillerons plus bas. |
|||
[[File:Nearby_messages.jpg|200px|right|thumb|Schéma de l'API Nearby Messages]] |
|||
'''Nearby Messages API''' |
|||
L'API Nearby Messages permet plutôt d'envoyer des messages entre appareils, de toute nature mais limités à une certaine taille. Elle rend donc possible des groupes de discussion ou encore la diffusion de ressources. Pour se servir de cette API, les développeur ont besoin de clés API fournies par un compte Google. Les appareils souhaitant communiquer doivent être connectés à internet mais pas nécessairement sur le même réseau Wifi. La communication est possible entre des appareils Android et IOS. |
|||
== Principe de fonctionnement == |
|||
Pour permettre cet appariement de proximité, les deux API vont mélanger les avantages et les inconvénients de technologies comme le Wifi, le Bluetooth (standard et BLE), et les ultrasons. |
|||
'''Nearby Connections API''' |
|||
Le principe de fonctionnement de Nearby Connections est assimilable a une architecture Client-Server (OneToMany). |
|||
[[File:Nearby-pre-connection-phase.jpg|500px|center|thumb|Schéma du fonctionnement de Nearby Connections]] |
|||
'''Nearby Messages API''' |
|||
Le principe de fonctionnement de Nearby Messages est assimilable a une architecture ManyToMany. |
|||
[[File:NearbyMessagesFonctionnement.jpg|thumb|400px|Schéma de fonctionnement de Nearby Messages]] |
|||
Comme on peut voir sur ce schéma, l'appareil A va envoyer une requête sur Google Cloud pour "s'inscrire" avec un Token (ici TA). Il peut également publier en même temps les données qu'il souhaite diffuser donc ici son nom "iPhone 6" avec le tag "name" (Étape 1). Comme on utilise le Cloud on a besoin des clés API et d'une connexion internet. |
|||
Pour obtenir ces données, le téléphone B soit "s'abonner" aux données marquées par le tag "name" (Étape 2). |
|||
L'appareil A va ensuite diffuser son Token aux appareils autour de lui grâce au Bluetooth et aux ultrasons, pendant que l'appareil B va écouter ce qu'il se passe autour de lui (Étape 3) |
|||
Une fois que B a capté le Token de A, il le signale au Cloud et récupère la donnée correspondante (Étape 4 et 5). |
|||
On constate donc qu'aucune donnée n'est physiquement échangée entre les deux appareils : tout transite par le Cloud. |
|||
'''Pourquoi utiliser ces moyens de communication ?''' |
|||
Utiliser un mélange de Bluetooth et d'Ultrasons permet de tirer partie des forces de chacun. |
|||
Les ultrasons communiquent via le haut parleur et le micro des appareils, ils ont une courte fréquence de transmission qui leur permet de ne pas traverser les murs. Et c'est ce qui ressemble à ce que l'utilisateur voudrait : que sa conversation ne sorte pas de la pièce. Mais si les hauts parleurs ou le micro d'un des deux terminal est éteint alors la communication est impossible. |
|||
C'est pour cela qu'elle est complétée par du Bluetooth. Celui ci est toujours disponible mais a une fréquence d'émission bien trop grande qui permet de traverser les murs. |
|||
Il y a donc un intérêt à mélanger ces deux modes de communications : la portée des ultrasons et la disponibilité du Bluetooth. |
|||
'''Et au niveau du code ?''' |
|||
Pour utiliser l'API Nearby Messages, on a besoin seulement de deux méthodes : publish (pour envoyer des messages) et subscribe (pour les recevoir). Les messages transmis sont des Bytes Array, qui peuvent contenir n'importe quel type de données dans n'importe quel encodage avec la seule limite de faire moins de 100 kiloBytes. |
|||
== Sécurité == |
|||
Vient maintenant la question de la sécurité. J’ai trouvé très peu d’informations sur l’utilisation exacte des différents capteurs donc du Bluetooth, BLE, du wifi ou encore des ultrasons dans ces différentes API. Google met simplement en avant le fait que les données sont cryptées, et que la proximité des utilisateurs amoindri considérablement le risque d’attaque. |
|||
J’ai donc lu un rapport de l’université d’Oxford qui a tenté de savoir quel était exactement le niveau de sécurité de Nearby Connections. Pour cela ils ont utilisé une technique de reverse engineering. Leur étude a tout d’abord montré que l'API est propriétaire, donc nous n’avons pas accès au code qui fait tourner l’outil. |
|||
Leur conclusion a été qu'en l'état actuel, l'API Nearby Connection de Google est non seulement ouverte aux attaques, mais constitue également une menace active pour les nombreux appareils sur lesquels elle est installée puisque les attaquants à proximité n’auraient aucun mal à se connecter à votre terminal. |
|||
On pourrait tirer les mêmes conclusions pour Nearby Messages sachant qu’en plus toutes les données circulent dans Google Cloud. |
|||
== Sources == |
|||
https://www.frandroid.com/android/developpement/296229_google-nearby-nouvelle-api-connexion-entre-terminaux-a-proximite |
|||
https://developers.google.com/nearby |
|||
https://medium.com/mobile-app-development-publication/android-nearby-connections-vs-messages-a2bdf6a59ff3 |
|||
https://www.cs.ox.ac.uk/files/10367/ndss19-paper367.pdf |
|||
http://blog.p2pkit.io/how-google-nearby-really-works-and-what-else-it-does/ |
|||
https://www.youtube.com/watch?time_continue=1&v=Acdu2ZdBaZE&feature=emb_title |
|||
= Veille Technologique 2020 = |
|||
* Année : [[VT2020]] |
|||
* Sujet : Nearby communications |
|||
* Slides : [[Media:VT_Nearby.pdf|Slides]] |
|||
* Auteur : Manon Chaix |
Latest revision as of 15:39, 14 December 2020
Nearby est une plateforme lancée par Google en 2014. Elle est composée de deux APIs, Nearby Connections et Nearby Messages. Ces APIs permettent de faciliter la connexion entre des appareils situés à proximité (par exemple de pouvoir s'envoyer un message sans avoir besoin d'un numéro de téléphone).
Description des API
Nearby est en réalité constitué de deux APIs : Nearby Connections et Nearby Messages. Elles apportent des services similaires mais avec des caractéristiques différentes.
Nearby Connections API
L'API Nearby Connections permet de créer une connexion locale entre des appareils à proximité en temps réel. Par exemple, elle rend possible d'associer des appareils et de s'en servir pour des jeux multijoueurs. La connexion est donc limitée au réseau local : tous les appareils doivent être sur le même réseau Wifi. La communication n'est possible qu'entre des appareils Android. Son principe de fonctionnement ressemble à une architecture Client-Serveur que nous détaillerons plus bas.
Nearby Messages API
L'API Nearby Messages permet plutôt d'envoyer des messages entre appareils, de toute nature mais limités à une certaine taille. Elle rend donc possible des groupes de discussion ou encore la diffusion de ressources. Pour se servir de cette API, les développeur ont besoin de clés API fournies par un compte Google. Les appareils souhaitant communiquer doivent être connectés à internet mais pas nécessairement sur le même réseau Wifi. La communication est possible entre des appareils Android et IOS.
Principe de fonctionnement
Pour permettre cet appariement de proximité, les deux API vont mélanger les avantages et les inconvénients de technologies comme le Wifi, le Bluetooth (standard et BLE), et les ultrasons.
Nearby Connections API
Le principe de fonctionnement de Nearby Connections est assimilable a une architecture Client-Server (OneToMany).
Nearby Messages API
Le principe de fonctionnement de Nearby Messages est assimilable a une architecture ManyToMany.
Comme on peut voir sur ce schéma, l'appareil A va envoyer une requête sur Google Cloud pour "s'inscrire" avec un Token (ici TA). Il peut également publier en même temps les données qu'il souhaite diffuser donc ici son nom "iPhone 6" avec le tag "name" (Étape 1). Comme on utilise le Cloud on a besoin des clés API et d'une connexion internet. Pour obtenir ces données, le téléphone B soit "s'abonner" aux données marquées par le tag "name" (Étape 2). L'appareil A va ensuite diffuser son Token aux appareils autour de lui grâce au Bluetooth et aux ultrasons, pendant que l'appareil B va écouter ce qu'il se passe autour de lui (Étape 3) Une fois que B a capté le Token de A, il le signale au Cloud et récupère la donnée correspondante (Étape 4 et 5). On constate donc qu'aucune donnée n'est physiquement échangée entre les deux appareils : tout transite par le Cloud.
Pourquoi utiliser ces moyens de communication ?
Utiliser un mélange de Bluetooth et d'Ultrasons permet de tirer partie des forces de chacun. Les ultrasons communiquent via le haut parleur et le micro des appareils, ils ont une courte fréquence de transmission qui leur permet de ne pas traverser les murs. Et c'est ce qui ressemble à ce que l'utilisateur voudrait : que sa conversation ne sorte pas de la pièce. Mais si les hauts parleurs ou le micro d'un des deux terminal est éteint alors la communication est impossible. C'est pour cela qu'elle est complétée par du Bluetooth. Celui ci est toujours disponible mais a une fréquence d'émission bien trop grande qui permet de traverser les murs. Il y a donc un intérêt à mélanger ces deux modes de communications : la portée des ultrasons et la disponibilité du Bluetooth.
Et au niveau du code ?
Pour utiliser l'API Nearby Messages, on a besoin seulement de deux méthodes : publish (pour envoyer des messages) et subscribe (pour les recevoir). Les messages transmis sont des Bytes Array, qui peuvent contenir n'importe quel type de données dans n'importe quel encodage avec la seule limite de faire moins de 100 kiloBytes.
Sécurité
Vient maintenant la question de la sécurité. J’ai trouvé très peu d’informations sur l’utilisation exacte des différents capteurs donc du Bluetooth, BLE, du wifi ou encore des ultrasons dans ces différentes API. Google met simplement en avant le fait que les données sont cryptées, et que la proximité des utilisateurs amoindri considérablement le risque d’attaque. J’ai donc lu un rapport de l’université d’Oxford qui a tenté de savoir quel était exactement le niveau de sécurité de Nearby Connections. Pour cela ils ont utilisé une technique de reverse engineering. Leur étude a tout d’abord montré que l'API est propriétaire, donc nous n’avons pas accès au code qui fait tourner l’outil. Leur conclusion a été qu'en l'état actuel, l'API Nearby Connection de Google est non seulement ouverte aux attaques, mais constitue également une menace active pour les nombreux appareils sur lesquels elle est installée puisque les attaquants à proximité n’auraient aucun mal à se connecter à votre terminal. On pourrait tirer les mêmes conclusions pour Nearby Messages sachant qu’en plus toutes les données circulent dans Google Cloud.
Sources
https://developers.google.com/nearby
https://www.cs.ox.ac.uk/files/10367/ndss19-paper367.pdf
http://blog.p2pkit.io/how-google-nearby-really-works-and-what-else-it-does/
https://www.youtube.com/watch?time_continue=1&v=Acdu2ZdBaZE&feature=emb_title