I wanted to chime in about this.
It's pretty easy, I'd say trivial to see if its the same device if you
where to look at an example of what network logs or dhcp logging may
look like:
```
| Time | Source MAC | Hostname | Destination MAC
| Protocol | Source Port | Destination Port | Length | Info
| Client IP |
|----------------|---------------------|------------|----------------------|----------|-------------|------------------|--------|--------------------------------|-------------------|
| 11:47:12.654 | 88:12:4e:5a:db:4c | | 00:25:86:df:9a:5e
| ARP | - | - | 42 | Who has
192.168.1.100? | 192.168.1.100 |
| 11:47:13.987 | 98:10:e8:64:55:da | Iphone16 | 00:25:86:df:9a:5e
| ARP | - | - | 42 | Who has
192.168.1.101? | 192.168.1.101 |
| 11:47:15.320 | 00:04:23:a2:8c:fb | Windows11 | 00:25:86:df:9a:5e
| ARP | - | - | 42 | Who has
192.168.1.102? | 192.168.1.102 |
| 11:47:16.653 | 88:12:4e:b4:36:4c | | 00:25:86:df:9a:5e
| ARP | - | - | 42 | Who has
192.168.1.103? | 192.168.1.103 |
| 11:47:18.986 | 88:12:4e:0a:16:a5 | | 00:25:86:df:9a:5e
| ARP | - | - | 42 | Who has
192.168.1.104? | 192.168.1.104 |
| 11:47:20.319 | 00:b3:62:96:a2:4d | JohnsPhone | 00:d0:e1:12:f6:ee
| TCP | 54321 | 80 | 1500 | HTTP GET
/index.html | 192.168.1.50 |
| 11:47:21.652 | 88:12:4e:fb:27:e9 | | 7c:1b:4d:22:8e:ef
| UDP | 12345 | 12345 | 100 | DNS Query
| 192.168.1.120 |
| 11:47:22.985 | 88:12:4e:d3:5f:e0 | | 40:61:86:2e:8f:9c
| ICMP | - | - | 56 | Echo Request
| 192.168.1.130 |
| 11:47:24.318 | 98:10:e8:64:55:da | Iphone16 | 34:21:9d:81:5f:4c
| TCP | 80 | 54321 | 1200 | HTTP Response
| 192.168.1.150 |
| 11:47:25.651 | 88:12:4e:1a:0e:0e | | 50:7b:9d:12:34:56
| ARP | - | - | 42 | Who has
192.168.1.105? | 192.168.1.105 |
| 11:47:27.984 | 00:04:23:a2:8c:fb | Windows11 | 60:1e:5c:3a:2b:4d
| ARP | - | - | 42 | Who has
192.168.1.106? | 192.168.1.106 |
```
All one has to do is look for devices with the same OUI in the MAC
address and no hostname...
(Bellow is the table in html if above doesn't format correctly in the email)
<table>
<tr>
<th>Time</th>
<th>Source MAC</th>
<th>Hostname</th>
<th>Destination MAC</th>
<th>Protocol</th>
<th>Source Port</th>
<th>Destination Port</th>
<th>Length</th>
<th>Info</th>
<th>Client IP</th>
</tr>
<tr>
<td>11:47:12.654</td>
<td>88:12:4e:5a:db:4c</td>
<td></td>
<td>00:25:86:df:9a:5e</td>
<td>ARP</td>
<td>-</td>
<td>-</td>
<td>42</td>
<td>Who has 192.168.1.100?</td>
<td>192.168.1.100</td>
</tr>
<tr>
<td>11:47:13.987</td>
<td>98:10:e8:64:55:da</td>
<td>Iphone16</td>
<td>00:25:86:df:9a:5e</td>
<td>ARP</td>
<td>-</td>
<td>-</td>
<td>42</td>
<td>Who has 192.168.1.101?</td>
<td>192.168.1.101</td>
</tr>
<tr>
<td>11:47:15.320</td>
<td>00:04:23:a2:8c:fb</td>
<td>Windows11</td>
<td>00:25:86:df:9a:5e</td>
<td>ARP</td>
<td>-</td>
<td>-</td>
<td>42</td>
<td>Who has 192.168.1.102?</td>
<td>192.168.1.102</td>
</tr>
<tr>
<td>11:47:16.653</td>
<td>88:12:4e:b4:36:4c</td>
<td></td>
<td>00:25:86:df:9a:5e</td>
<td>ARP</td>
<td>-</td>
<td>-</td>
<td>42</td>
<td>Who has 192.168.1.103?</td>
<td>192.168.1.103</td>
</tr>
<tr>
<td>11:47:18.986</td>
<td>88:12:4e:0a:16:a5</td>
<td></td>
<td>00:25:86:df:9a:5e</td>
<td>ARP</td>
<td>-</td>
<td>-</td>
<td>42</td>
<td>Who has 192.168.1.104?</td>
<td>192.168.1.104</td>
</tr>
<tr>
<td>11:47:20.319</td>
<td>00:b3:62:96:a2:4d</td>
<td>JohnsPhone</td>
<td>00:d0:e1:12:f6:ee</td>
<td>TCP</td>
<td>54321</td>
<td>80</td>
<td>1500</td>
<td>HTTP GET /index.html</td>
<td>192.168.1.50</td>
</tr>
<tr>
<td>11:47:21.652</td>
<td>88:12:4e:fb:27:e9</td>
<td></td>
<td>7c:1b:4d:22:8e:ef</td>
<td>UDP</td>
<td>12345</td>
<td>12345</td>
<td>100</td>
<td>DNS Query</td>
<td>192.168.1.120</td>
</tr>
<tr>
<td>11:47:22.985</td>
<td>88:12:4e:d3:5f:e0</td>
<td></td>
<td>40:61:86:2e:8f:9c</td>
<td>ICMP</td>
<td>-</td>
<td>-</td>
<td>56</td>
<td>Echo Request</td>
<td>192.168.1.130</td>
</tr>
<tr>
<td>11:47:24.318</td>
<td>98:10:e8:64:55:da</td>
<td>Iphone16</td>
<td>34:21:9d:81:5f:4c</td>
<td>TCP</td>
<td>80</td>
<td>54321</td>
<td>1200</td>
<td>HTTP Response</td>
<td>192.168.1.150</td>
</tr>
<tr>
<td>11:47:25.651</td>
<td>88:12:4e:1a:0e:0e</td>
<td></td>
<td>50:7b:9d:12:34:56</td>
<td>ARP</td>
<td>-</td>
<td>-</td>
<td>42</td>
<td>Who has 192.168.1.105?</td>
<td>192.168.1.105</td>
</tr>
<tr>
<td>11:47:27.984</td>
<td>00:04:23:a2:8c:fb</td>
<td>Windows11</td>
<td>60:1e:5c:3a:2b:4d</td>
<td>ARP</td>
<td>-</td>
<td>-</td>
<td>42</td>
<td>Who has 192.168.1.106?</td>
<td>192.168.1.106</td>
</tr>
</table>
On 6/15/25 00:54, Joe via Tails-dev wrote:
> Dear Tails Development Team,
>
> I hope this message finds you well. I am writing to bring to your
> attention an important consideration regarding the MAC spoofing feature
> in Tails. The existing MAC spoofing feature in Tails OS is a step in the
> right direction, as it checks for NIC existence and retries if
> necessary, treating the NIC as a unique identifier for WiFi cards. While
> the current implementation effectively changes the NIC part of the MAC
> address, it leaves the OUI (Organizationally Unique Identifier) exposed,
> which can potentially compromise user anonymity.
>
> The OUI part of the MAC address identifies the device manufacturer, and
> if left unchanged, it can be used for device fingerprinting. This is
> particularly concerning for users such as journalists and whistleblowers
> who rely on Tails for privacy. The current setup inadvertently makes
> these users unique, as the OUI remains constant, even when the NIC is
> spoofed.
>
> As noted in the Tails documentation on MAC address limitations, tools
> like Macchiato may rely on outdated OUI lists, potentially increasing
> uniqueness. Ironically, the current Tails implementation already risks
> this by maintaining a consistent OUI, making it trivial for entities
> like ISPs to track devices across sessions. If you are using tails at
> home your ISP or anyone monitoring your network that its the same device
> on the network since the OUI is always the same.
>
> This especially true for users on dedicated devices such as journalists
> or whistleblowers. I'm sure many journalists, whistleblowers, or privacy
> folks may strictly have a separate computer or throwaway dedicated
> device that they only use with Tails. Well, those devices most likely
> have a common or unique OUI especially if they are older devices. Many
> such users might also attempt mitigations, like purchasing external
> ethernet or WiFi adapters, but this often deanons them through traceable
> purchases since most are going to purchase these through sites like
> Amazon which require credit cards.
>
> Mind you the best case of action would to be spoofing both OUI and NIC
> in the mac address design. Most notably android and Iphone already
> support this and do this though their design is flawed since it is only
> per network and not per connection to a network. Up until recently it
> was discovered that iOS prior to version 17.1, leaked real MAC on port 5353.
>
> * Proposed Solution *
>
> To enhance anonymity, I propose spoofing both the OUI and NIC parts of
> the MAC address. While systems like Android and iOS have similar
> implementations, they are limited to per-network changes. However, the
> approach can be adapted and improved for Tails.
>
> * DHCP Considerations *
>
> When implementing full MAC spoofing, it's crucial to handle DHCP leasing
> correctly. If a spoofed MAC is already leased, the device may fail to
> obtain an IP address or fail to connect to the internet. To mitigate
> this, I suggest integrating an ARP check using `arping` to ensure the
> new MAC is not already in use before connecting.
>
> If the DHCP server detects that the MAC address is already associated
> with an active lease, it may refuse to assign a new IP address to your
> system. Send a DHCP NAK (negative acknowledgment) to your system,
> indicating that it cannot assign an IP address. If does the allow you to
> connect with an already leased MAC you most likely will not be able to
> connect to the internet. In environments with MAC spoofing detection,
> such as those using Dynamic ARP Inspection (DAI), the spoofed ARP
> requests could be ignored or flagged, potentially leading to no
> responses. However, these advanced security features are less common on
> public WiFi networks with captive portals, where basic DHCP setups
> predominate, reducing the likelihood of such detections.
>
> To my knowledge NetworkManager or Linux in general will not explicitly
> retry with a new spoofed mac if there is already is a device leased with
> the same MAC address already on a network.
> Currently it looks like `iputils-arping` is not installed on tails but
> could possibly be incorporated into the existing design?
>
> * Example Code Implementation *
>
> The following is example code modifications that could can be
> incorporated to include the ARP check:
>
> **Modify `spoof_mac` Function:**
>
> ```bash
> spoof_mac() {
> local max_retries=3
> local attempt=1
> local msg
> local new_mac
> local gateway_ip
>
> gateway_ip=$(ip route show | grep default | awk '{print $3}')
>
> set +e
> while [ "${attempt}" -le "${max_retries}" ]; do
> msg="$(macchanger -e "${1}" 2>&1)"
> ret="${?}"
> set -e
>
> if [ "${ret}" != 0 ]; then
> log "macchanger failed for NIC ${1}, returned ${ret} and
> said: ${msg}"
> unset NEW_MAC
> break
> fi
>
> NEW_MAC="$(get_current_mac_of_nic "${1}")"
> if [ "${OLD_MAC}" != "${NEW_MAC}" ]; then
> log "Spoofed MAC for NIC ${1} is: ${NEW_MAC}"
> log "Checking if MAC ${NEW_MAC} is already leased..."
>
> if arping -c 1 -I "${1}" -s "${NEW_MAC}" "${gateway_ip}"
> &> /dev/null; then
> log "MAC ${NEW_MAC} is already leased or in use on NIC
> ${1}."
> attempt=$((attempt + 1))
> continue
> else
> log "No conflict detected for MAC ${NEW_MAC}."
> return 0
> fi
> fi
> attempt=$((attempt + 1))
> done
> set +e
> return 1
> }
> ```
>
> **Add Error Handling and Logging:**
>
> ```bash
> for i in 1 2 3; do
> if ! spoof_mac "${NIC}"; then
> unset NEW_MAC
> break
> fi
> NEW_MAC="$(get_current_mac_of_nic "${NIC}")"
> if [ "${OLD_MAC}" != "${NEW_MAC}" ]; then
> log "Checking if MAC ${NEW_MAC} is already leased..."
> if arping -c 1 -I "${NIC}" -s "${NEW_MAC}" "${gateway_ip}" &> /
> dev/null; then
> log "MAC ${NEW_MAC} is already leased, retrying spoofing..."
> continue
> fi
> break
> fi
> done
> ```
>
>
> Enhancing MAC spoofing to include both OUI and NIC, along with ARP
> checks, would significantly improve user anonymity in Tails and avoid
> failure if a leased device on a network already has the same MAC as the
> Spoofed one. If there is not way to anonymously check DHCP leases with
> leaking the real MAC address through ARP ping/requests then forget this
> but rather focus on new mac spoofing design that spoofs full mac address.
>
> Thank you for your dedication to Tails and user privacy.
>
> Namaste,
>
> Joe
>
> _______________________________________________
> Tails-dev mailing list
> Tails-dev@???
> https://www.autistici.org/mailman/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to Tails-dev-unsubscribe@???.
