MétaCan
Menu
Retour à la cohorte
Enregistrement W6944743493 · doi:10.21227/5q11-z704

CRAWDAD toronto/bluetooth

2022· dataset· en· W6944743493 sur OpenAlexaffabout

Notice bibliographique

RevueIEEE DataPort · 2022
Typedataset
Langueen
Domaine
Thématique
Établissements canadiensUniversity of Toronto
Organismes subventionnairesnon disponible
Mots-clésBluetoothWirelessProtocol (science)Vulnerability (computing)Host (biology)

Résumé

récupéré en direct d'OpenAlex

To investigate whether a large-scale Bluetooth worm outbreak is viable in practice, we conducted controlled experiments and we gathered traces of Bluetooth activity in different urban environments to determine the feasibility of a worm infection.   date/time of measurement start: 2005-11-16date/time of measurement end: 2005-11-26  collection environment: Even if a worm could exploit a security vulnerability in the Bluetooth protocol to replicate itself, a large-scale Bluetooth worm outbreak might never develop. If vulnerable Bluetooth devices are few and far between, and most inter-device contacts are short, a worm might never reach many victims. In this case, the threat of a largescale Bluetooth worm infection is minimal. To investigate these questions, we examined whether a large-scale Bluetooth worm outbreak is viable in practice. For this, we collected traces of Bluetooth activity and conducted controlled experiments in a Bluetooth environment.network configuration: We used Palm Tungsten T PDAs having 16MB of RAM with PalmOS version 5.0 to scan for Bluetooth devices. The Bluetooth radios of our PDAs are similar to the ones found in most commodity cell-phones: our empirical tests found that our PDAs' ranges are about 10 meters in an urban environment corresponding to the specifications presented on Palm's website. Because a Bluetooth inquiry is a power-intensive procedure, we used a total of eight scanners. Each device sends "inquiries" over its Bluetooth interface. Our inquiry rate is variable: we increase it when no devices are discovered, and we decrease it when others answer our probes. We issue inquiries at least once every 10 seconds but never more often than once every 3 seconds. This variable rate deals with congestion scenarios when several devices answer simultaneously.data collection methodology: We collected three different traces of Bluetooth activity. Two of our traces are gathered inside Pacific Mall and Eaton Centre, two malls in Toronto, Canada. We gathered the third trace while riding the Toronto subway system. These three locations provide a broad coverage of different density and mobility characteristics one might find in various urban destinations. When collecting these traces, we had a behavior compatible to the environment we were scanning. For example, we were casually walking in the malls, we stopped briefly by their food courts, and we stood still while riding the subway. In this way, our data illustrates a scenario where an attacker behaves inconspicuously while launching a Bluetooth worm. We used two devices scanning simultaneously to collect the Eaton Centre and the Subway traces. We used only one device to collect the Pacific Mall trace.sanitization: We have anonymized the MAC addresses of the discovered devices.Tracesettoronto/bluetooth/encountering Traceset of Bluetooth activity in different urban environment.files: pacificMall.txt, eatonCenter.txt, subway.txtdescription: Traceset of Bluetooth activity in three different locations which have different density and mobility characteristics one might find in various urban destinations.measurement purpose: Network Security, Computer Malware (Worms) Investigationmethodology: We collected three different traces of Bluetooth activity. Two of our traces are gathered inside Pacific Mall and Eaton Centre, two malls in Toronto, Canada. We gathered the third trace while riding the Toronto subway system. These three locations provide a broad coverage of different density and mobility characteristics one might find in various urban destinations.sanitization: if the same foreign device answers multiple consecutive Bluetooth inquiries except one, we "patch" the missed Bluetooth inquiry, pretending the device answered the inquiry. If the foreign device misses two consecutive Bluetooth inquiries, we do not "patch" the encounter. We have anonymized the MAC addresses of the discovered devices. We preserved the first three octets of the original MAC address, however we have generated random three octets for the last three octects of the MAC address. In short: anonymized_MAC = first_3_octets(orig_MAC) + random_3_octetstoronto/bluetooth/encountering TracespacificMall: Trace of Bluetooth activity in Pacific Mall, a mall in Toronto, Canadaconfiguration: Each line in the file corresponds to one "encountering", where one of our scanners encountered a foreign Bluetooth device. One encounter is a sequence of several (one or more) consecutive successful Bluetooth inquiries. Each encounter has a start time (the time of the first Bluetooth inquiry answered by the encountered device) and an end time (the time of the last Bluetooth inquiry answered by the encountered device.)format:  Here's a breakdown of the format, column by column:1. 32-bit timestamp: the encounter start time.2. same timestamp as per #1, but in a human readable format3. 32-bit timestamp: the encounter end time4. same timestamp as per #3, but in a human readable format5. location (one of EATON_CENTER, PACIFIC_MALL, or SUBWAY).6. scanner ID7. anonymized MAC address of foreign Bluetooth device encountered.8. type of Bluetooth device9. manufacturer of Bluetooth deviceeatonCenter: Trace of Bluetooth activity in Eaton Centre, a mall in Toronto, Canada.configuration: Each line in the file corresponds to one "encountering", where one of our scanners encountered a foreign Bluetooth device. One encounter is a sequence of several (one or more) consecutive successful Bluetooth inquiries. Each encounter has a start time (the time of the first Bluetooth inquiry answered by the encountered device) and an end time (the time of the last Bluetooth inquiry answered by the encountered device.)format: Here's a breakdown of the format, column by column:1. 32-bit timestamp: the encounter start time.2. same timestamp as per #1, but in a human readable format3. 32-bit timestamp: the encounter end time4. same timestamp as per #3, but in a human readable format5. location (one of EATON_CENTER, PACIFIC_MALL, or SUBWAY).6. scanner ID7. anonymized MAC address of foreign Bluetooth device encountered.8. type of Bluetooth device9. manufacturer of Bluetooth devicesubway: Trace of Bluetooth activity gathered while riding the Toronto subway system.configuration: Each line in the file corresponds to one "encountering", where one of our scanners encountered a foreign Bluetooth device. One encounter is a sequence of several (one or more) consecutive successful Bluetooth inquiries. Each encounter has a start time (the time of the first Bluetooth inquiry answered by the encountered device) and an end time (the time of the last Bluetooth inquiry answered by the encountered device.)format: Here's a breakdown of the format, column by column:1. 32-bit timestamp: the encounter start time.2. same timestamp as per #1, but in a human readable format3. 32-bit timestamp: the encounter end time4. same timestamp as per #3, but in a human readable format5. location (one of EATON_CENTER, PACIFIC_MALL, or SUBWAY).6. scanner ID7. anonymized MAC address of foreign Bluetooth device encountered.8. type of Bluetooth device9. manufacturer of Bluetooth device toronto/bluetooth/controlledfiles: bluetooth_traces.tar.gz, xfers.txt, controlled.txtdescription: Traceset of controlled experiments for Bluetooth activity.measurement purpose: Network Security, Computer Malware (Worms) Investigationmethodology: We conducted two controlled experiments as follows:1. toronto/bluetooth/controlled/xfersWe measured the throughput and the failure rate of transmissions between two devices we controlled. We transfered a 256KB file between two devices placed apart at different the throughput and the failure rate of transmissions between two devices we controlled. We transfered a 256KB file between two devices placed apart at different 2. toronto/bluetooth/controlled/moving We also conducted the controlled experiments of communicating over Bluetooth between two devices when only one is moving.toronto/bluetooth/controlled Tracesxfers: Trace of measurement of Bluetooth transfers performed in different environments.configuration: This trace contains the measurements of Bluetooth transfers performed in different environments. We measured how long it took to transfer 256KB between two stationary Bluetooth devices while they are K feet apart (for K between 0 and 25).format: Here's a breakdown of the format, column by column:This is a breakdown of the file's format, column by column:1. inter-device distance in feet2. data successfully transfered (out of 256032 bytes)3. duration of transfer (in seconds) moving: Trace of measurements of Bluetooth transfer performed in a controlled environment (our lab).configuration: We conducted controlled experiments to determine whether walking can prevent a person's device from becoming infected. We placed one device on a wall at a T-junction hallway, while a person carried another device pacing themselves at a constant speed. The mobile device first issued inquiry requests. Once the stationary device is discovered, the mobile device transmitted a file. We performed several experiments. We set the size of the file at 500 bytes and at 25KB. We moved the mobile device at a speed of 1 m/s, corresponding to a typical walking speed, and 2 m/s, to approximate the relative speed of two people walking in opposite directions. Each experiment is repeated five times. We chose the T-junction hallway because it combines both line-of-sight and obstructed inter-device transmissions. There are five trials for each setting of moving device's speed and transfer data (except when we are transffering 25KB and the device is moving at 2m/s; in this case, we only have four successful trials.)format: 1. moving device's sp

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.

Comment cette classification a été obtenuedéplier

Prédiction distillée sur la base complète

Imitation des enseignants

Ni prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.

score de la tête « metaresearch » (Codex)0,001
score de la tête « metaresearch » (Gemma)0,000
Version: codex-gemma-dda1882f352aStatut de validation: machine_predicted_unvalidated
Catégories candidatesMéta-épidémiologie (sens strict), Charge utile insuffisante (le modèle a refusé de juger)
Catégories consensuellesCharge utile insuffisante (le modèle a refusé de juger)
DomaineSignal candidat: aucune · Signal consensuel: aucune
Devis d'étudeSignal candidat: Sans objet · Signal consensuel: Sans objet
GenreSignal candidat: Jeu de données · Signal consensuel: Jeu de données
Score de désaccord entre enseignants0,509
Score d'incertitude au seuil0,999

Scores Codex et Gemma par catégorie

CatégorieCodexGemma
Métarecherche0,0010,000
Méta-épidémiologie (sens strict)0,0010,001
Méta-épidémiologie (sens large)0,0010,000
Bibliométrie0,0000,000
Études des sciences et des technologies0,0000,000
Communication savante0,0000,001
Science ouverte0,0040,001
Intégrité de la recherche0,0000,001
Charge utile insuffisante (le modèle a refusé de juger)0,5400,032

Scores machine (provisoires)

Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.

Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.

Tête enseignante Opus0,028
Tête enseignante GPT0,310
Écart entre enseignants0,282 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validationscore_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle

Classification

machine, non validée

Prédiction automatique; les deux têtes enseignantes s’accordent sur ce qui est montré ici.

Devis d'étudeSans objet
Domainenon disponible
GenreJeu de données

Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».

En bref

Citations0
Publié2022
Routes d'admission2
Résumé présentoui

Explorer davantage

Même revueIEEE DataPortTravaux en français237 207