7 ms·

The salient bit: Police found him by tracking his Internet Protocol (IP) address online first, and then taking it to Verizon Wireless, the Internet service pro

The salient bit: Police found him by tracking his Internet Protocol (IP) address online first, and then taking it to Verizon Wireless, the Internet service provider connected with the account. Verizon provided records that showed that the AirCard associated with the IP address was transmitting through certain cell towers in certain parts of Santa Clara. Likely by using a stingray, the police found the exact block of apartments where Rigmaiden lived.

ggm 8y ago
Lest anyone believe their positional privacy is at risk, even the Verizon routing prefix could have homed the cops onto which provider to drill down into. The take-away here, is that end-to-end protocols by neccessity as currently written send the src IP in the packet. If we'd designed IP to send the src IP as a payload, and had encrypted payload (TLS style) and then only had the destination IP in the outer packet, things might be different. I've asked this question over the years since the 1980s: Given that we thought source based routing was a thing, its understandable we designed for simpler times with src IP in the packet but given its not a thing now, and privacy is, why do we still send the src IP in the packet? It doesn't mean anything useful, to most agents. NAT/CGN devices don't actually care, they want you to be consistent about which interface you arrive on, and the 5-tuple has it, but other things could be used which have no end-to-end impact. Beyond the NAT/CGN boundary, nobody cares, routing is solely on the destination and the ASN of the transits. Once at the destination, the payload is available, to find the originators address, to return things. Src IP is not actually neccessary, in the IP layer. (in theory)
- xyzzyz 8y ago
  If the source IP is encrypted, the recipient needs to decrypt it first in order to be able to send a response. To decrypt it, it needs to either have some shared secret with the sender, or the sender needs to use the recipient's private key. The parties cannot obtain the shared secret the usual way, the Diffie-Helman exchange. It cannot be performed, because it requires back-and-forth communication, which we are trying to establish in the first place. Of course, we'd still need to use certificates signed by public authorities to deal with the standard MitM concerns. The alternative would be for the sender to use the recipient's public key to encrypt the source IP address. That would require a DNS-like system that would store and serve public keys corresponding to a given IP address you are trying to communicate with. This is something doable, especially in IPv6 world where you don't really have to reuse IPv6 addresses, but it leads to all kinds of practical problems, figuring out which is probably best left as an exercise for the reader.
  - eftychis 8y ago
    Nit-picking a bit/kind of augmenting your train of thought. You can have non-interactive Diffie-Helman key exchange (via a PKI). As you say, the client would need to know prior to that the public key/have access to the certificate and that would require certainly revamping the DNS approach we now have (even if we did not use DNS, we would still have to deal with DNS requests).
    - xyzzyz 8y ago
      That's literally the second option I describe. What is your point?
      - schrodinger 8y ago
        Your tone is unnecessarily harsh.
      - therein 8y ago
        What you guys are describing is starting to sound more and more like onion routing.
        User23 8y ago
        Point is online security is a bad joke. You wrote it, you own it. The real interesting question is what happens when you get owned by what you didn't write?
      - eftychis 8y ago
        Just wanted to clarify that the issue was not with the Diffie-Hellman key exchange itself, but the way we currently do DNS plus IP routing are the issues. Technically, the client could encrypt their IP with the y=H(g^{scr}) key (result of the DH KE) and send (Enc(y, IP), g^{rc})-- where H is the oracle, g^s server public key, rc <session nonce>*key (or generally 1 time key). The server can then compute the same key (g^{rc}^s and then apply H) and decrypt. So the second and third paragraph contradict a bit each other, which was the sole reason for my clarification. I am not stating you as wrong or anything; I was just augmenting, so other readers don't get the wrong impression and decouple Diffie-Hellman KE from public key cryptography. P.S. The remaining issue is to make sure the server does not have to decrypt the IP for invalid connections etc (that is avoid DOS or leaking secrets as we are operating on not trusted ciphertext).
- Ao7bei3s 8y ago
  * Secure handshaking requires interactivity, unless you share secrets with your actual partner (no, your CA trust store isn't enough) in advance. So your first packet would leak it. * To return ICMP error messages ("destination unreachable"), otherwise you'd have long timeouts. * Ratelimiting outside the server (e.g. DDOS protection). Many ISPs do actually filter source IPs. (Of course you can't on the backbone, any there are plenty shady AS.) * Leaving it off won't help against correlation attacks. * Most applications will need it, so it makes sense to have it in the network layer instead of coming up with incompatible implementations above.
  - ra1n85 8y ago
    +RPF requires it to help prevent spoofing (BCP 38)
    - ggm 8y ago
      Like AS PATH this is one of the reasons people say but like path security in BGP, its not what people actually do very much. I like BCP38 and I like MANRS but.. traction is hard here. I was making statements about the road not taken: we have dst IP in the packets, from before BCP existed.
    - caf 8y ago
      In our thought-experiment world where each address has a public key that can be used to encrypt the payload data destined for it, the public key of the source can also be used to sign the data, ensuring the sender address isn't spoofed.
      - ra1n85 8y ago
        What validates that - the destination or intermediate devices? Spoofing is often just a means for volumetric DDoS attacks - if the destination is responsible for validate sources then we’re no better off there.
        caf 8y ago
- mehrdadn 8y ago
  How would you return errors if the destination is known to be unreachable?
  - droopybuns 8y ago
    Or how would you troubleshoot which hop was the source of a routing problem without including a source IP to send a message back to. These kinds of discussions seem utterly divorced from the reality of networking to me.
    - ggm 8y ago
      Oh. we talked about that. You could include the origin-AS and each AS along the path would change it in flight, was one idea. Which also didn't fly for obvious reasons. src,dst pair as part of a tuple was just simpler.
      - hueving 8y ago
        AS != hop, especially when BGP isn't even present (e.g. Large private networks).
- ra1n85 8y ago
  There's way too much baked into the current infrastructure (and two instances of layer 3) for this to be feasible. Access-control lists used for filtering, identifying candidate address for services like NAT, and critical data plane operations like path MTU discovery all rely on the source address being available in the IP header. Sure we could re-engineer things to not be this way, but at what cost? Realistically (and unfortunately), if you don't want to be tracked then you're going to need to do some combination of tunneling, proxying, and encrypting.
  - ggm 8y ago
    Yes. It wasn't a statement about the future, as much as about the past.
- cantrevealname 8y ago
  > Src IP is not actually neccessary, in the IP layer. I like your thoughts, but I don't understand how it would have helped in the Hacker-Verizon-Stingray case. First, an analogy: Suppose no one ever wrote a return address on postal letters. People wrote only the destination. The recipient has to open the envelope to see who wrote the letter. The postal system still works and it's way more private. However, if the authorities are watching your particular mailbox at your house, copying the outside of every incoming and outgoing letter, what privacy have you gained? They still know who you wrote to and who replied. Now back to the Hacker-Verizon-Stingray case: When the hacker connects to Verizon, his phone must identify him as a Verizon customer at some protocol layer. The identifying info could be IMEI, IMSI, or Verizon account number. Otherwise anyone could use Verizon for free if there were no account. Likewise, when Verizon transmits info back to the hacker, Verizon has to know which cellphone it should go to, or at least which cell tower. In your design, the outbound packets from hacker to Verizon contain cleartext destination IP, but the src IP is encrypted. Fine, but then the Stingray finds the Verizon account number associated with that connection -- that info being available at some protocol layer. The Stingray then watches for any connections from Verizon back to the hacker that use the same Verizon account number. The Stingray thus collects both sides of the connection just as before. Am I missing something?
  - kryogen1c 8y ago
    I'm not an expert, but I believe what you're missing is the current legal gray area of meta data like IP addresses. Pulling account numbers associated with contracted accounts sounds more like it needs a warrant.
- hueving 8y ago
  Putting the return IP encrypted in the payload breaks NAT (see FTP helpers). You do understand that the IP that the return traffic is destined for has to initially be addressed to the IP of the NAT device, not what the client thinks its IP is, right?
  - ikiris 8y ago
    And nothing of value was lost :)
    - hueving 8y ago
      Well except nat doesn't work and the ipv4 internet (which is the vast majority of it) is broken. I wouldn't call the vast majority of the internet something without value.
- cornholio 8y ago
  Despite the gargantuan effort, you wouldn't actually gain substantial privacy from such a move. True, a single packet wouldn't identify both parties, but an exchange of packets in rapid succession, a TCP handshake or even an UDP stream would immediately leak the same information to any interested hop in the network. Furthermore, eavesdropping for metadata on the line is one of the lesser privacy concerns for most people. What really matters are privacy violations by the providers higher up the stack, where the address of both endpoints must be known to enable communication.
mirimir 8y ago
Yes, this was the key fail. If he'd been careful enough not to leak his IP address, he would arguably have remained free. I was, for example, using VPN services and Tor well before 2008. And I've never been more than a gray-hat hobbyist sort of "hacker". Anyone seriously into criminal activity who didn't reliably hide their IP address was a fool, even then. My point isn't to dump on Rigmaiden. It's just that articles like this contribute to the FUD about privacy being impossible now. The reality is that most criminals have horrible OPSEC. Especially when they're just getting started. And then they're careless about historical connections.
- thomastjeffery 8y ago
  IMHO, it's less about privacy being impossible, and more about privacy being difficult and expensive.
  - mirimir 8y ago
    I don't dispute that it's difficult. But expensive? How so?
    - thomastjeffery 8y ago
      Any decent VPN service has a monthly cost. That isn't trivial for everyone.
      - mirimir 8y ago
        One can get decent VPNs for ~$3 per month. The free version of SecurityKISS is good too, although it's capped at 300MB per day, and offers only 5-10 exit IP addresses.
- boomboomsubban 8y ago
  What anonymous methods would he have had of buying VPN access? Mailing cash? And if there wasn't stingray technology available, all the IP address could tell them was he was in the San Jose area, which the mail already told them.
LoSboccacc 8y ago
> Likely by using a stingray Article title: “proved”

ggm 8y ago

Lest anyone believe their positional privacy is at risk, even the Verizon routing prefix could have homed the cops onto which provider to drill down into. The take-away here, is that end-to-end protocols by neccessity as currently written send the src IP in the packet. If we'd designed IP to send the src IP as a payload, and had encrypted payload (TLS style) and then only had the destination IP in the outer packet, things might be different. I've asked this question over the years since the 1980s: Given that we thought source based routing was a thing, its understandable we designed for simpler times with src IP in the packet but given its not a thing now, and privacy is, why do we still send the src IP in the packet? It doesn't mean anything useful, to most agents. NAT/CGN devices don't actually care, they want you to be consistent about which interface you arrive on, and the 5-tuple has it, but other things could be used which have no end-to-end impact. Beyond the NAT/CGN boundary, nobody cares, routing is solely on the destination and the ASN of the transits. Once at the destination, the payload is available, to find the originators address, to return things. Src IP is not actually neccessary, in the IP layer. (in theory)

xyzzyz 8y ago
If the source IP is encrypted, the recipient needs to decrypt it first in order to be able to send a response. To decrypt it, it needs to either have some shared secret with the sender, or the sender needs to use the recipient's private key. The parties cannot obtain the shared secret the usual way, the Diffie-Helman exchange. It cannot be performed, because it requires back-and-forth communication, which we are trying to establish in the first place. Of course, we'd still need to use certificates signed by public authorities to deal with the standard MitM concerns. The alternative would be for the sender to use the recipient's public key to encrypt the source IP address. That would require a DNS-like system that would store and serve public keys corresponding to a given IP address you are trying to communicate with. This is something doable, especially in IPv6 world where you don't really have to reuse IPv6 addresses, but it leads to all kinds of practical problems, figuring out which is probably best left as an exercise for the reader.
- eftychis 8y ago
  Nit-picking a bit/kind of augmenting your train of thought. You can have non-interactive Diffie-Helman key exchange (via a PKI). As you say, the client would need to know prior to that the public key/have access to the certificate and that would require certainly revamping the DNS approach we now have (even if we did not use DNS, we would still have to deal with DNS requests).
  - xyzzyz 8y ago
    That's literally the second option I describe. What is your point?
    - schrodinger 8y ago
      Your tone is unnecessarily harsh.
    - therein 8y ago
      What you guys are describing is starting to sound more and more like onion routing.
      - User23 8y ago
        Point is online security is a bad joke. You wrote it, you own it. The real interesting question is what happens when you get owned by what you didn't write?
    - eftychis 8y ago
      Just wanted to clarify that the issue was not with the Diffie-Hellman key exchange itself, but the way we currently do DNS plus IP routing are the issues. Technically, the client could encrypt their IP with the y=H(g^{scr}) key (result of the DH KE) and send (Enc(y, IP), g^{rc})-- where H is the oracle, g^s server public key, rc <session nonce>*key (or generally 1 time key). The server can then compute the same key (g^{rc}^s and then apply H) and decrypt. So the second and third paragraph contradict a bit each other, which was the sole reason for my clarification. I am not stating you as wrong or anything; I was just augmenting, so other readers don't get the wrong impression and decouple Diffie-Hellman KE from public key cryptography. P.S. The remaining issue is to make sure the server does not have to decrypt the IP for invalid connections etc (that is avoid DOS or leaking secrets as we are operating on not trusted ciphertext).
Ao7bei3s 8y ago
* Secure handshaking requires interactivity, unless you share secrets with your actual partner (no, your CA trust store isn't enough) in advance. So your first packet would leak it. * To return ICMP error messages ("destination unreachable"), otherwise you'd have long timeouts. * Ratelimiting outside the server (e.g. DDOS protection). Many ISPs do actually filter source IPs. (Of course you can't on the backbone, any there are plenty shady AS.) * Leaving it off won't help against correlation attacks. * Most applications will need it, so it makes sense to have it in the network layer instead of coming up with incompatible implementations above.
- ra1n85 8y ago
  +RPF requires it to help prevent spoofing (BCP 38)
  - ggm 8y ago
    Like AS PATH this is one of the reasons people say but like path security in BGP, its not what people actually do very much. I like BCP38 and I like MANRS but.. traction is hard here. I was making statements about the road not taken: we have dst IP in the packets, from before BCP existed.
  - caf 8y ago
    In our thought-experiment world where each address has a public key that can be used to encrypt the payload data destined for it, the public key of the source can also be used to sign the data, ensuring the sender address isn't spoofed.
    - ra1n85 8y ago
      What validates that - the destination or intermediate devices? Spoofing is often just a means for volumetric DDoS attacks - if the destination is responsible for validate sources then we’re no better off there.
      - caf 8y ago
mehrdadn 8y ago
How would you return errors if the destination is known to be unreachable?
- droopybuns 8y ago
  Or how would you troubleshoot which hop was the source of a routing problem without including a source IP to send a message back to. These kinds of discussions seem utterly divorced from the reality of networking to me.
  - ggm 8y ago
    Oh. we talked about that. You could include the origin-AS and each AS along the path would change it in flight, was one idea. Which also didn't fly for obvious reasons. src,dst pair as part of a tuple was just simpler.
    - hueving 8y ago
      AS != hop, especially when BGP isn't even present (e.g. Large private networks).
ra1n85 8y ago
There's way too much baked into the current infrastructure (and two instances of layer 3) for this to be feasible. Access-control lists used for filtering, identifying candidate address for services like NAT, and critical data plane operations like path MTU discovery all rely on the source address being available in the IP header. Sure we could re-engineer things to not be this way, but at what cost? Realistically (and unfortunately), if you don't want to be tracked then you're going to need to do some combination of tunneling, proxying, and encrypting.
- ggm 8y ago
  Yes. It wasn't a statement about the future, as much as about the past.
cantrevealname 8y ago
> Src IP is not actually neccessary, in the IP layer. I like your thoughts, but I don't understand how it would have helped in the Hacker-Verizon-Stingray case. First, an analogy: Suppose no one ever wrote a return address on postal letters. People wrote only the destination. The recipient has to open the envelope to see who wrote the letter. The postal system still works and it's way more private. However, if the authorities are watching your particular mailbox at your house, copying the outside of every incoming and outgoing letter, what privacy have you gained? They still know who you wrote to and who replied. Now back to the Hacker-Verizon-Stingray case: When the hacker connects to Verizon, his phone must identify him as a Verizon customer at some protocol layer. The identifying info could be IMEI, IMSI, or Verizon account number. Otherwise anyone could use Verizon for free if there were no account. Likewise, when Verizon transmits info back to the hacker, Verizon has to know which cellphone it should go to, or at least which cell tower. In your design, the outbound packets from hacker to Verizon contain cleartext destination IP, but the src IP is encrypted. Fine, but then the Stingray finds the Verizon account number associated with that connection -- that info being available at some protocol layer. The Stingray then watches for any connections from Verizon back to the hacker that use the same Verizon account number. The Stingray thus collects both sides of the connection just as before. Am I missing something?
- kryogen1c 8y ago
  I'm not an expert, but I believe what you're missing is the current legal gray area of meta data like IP addresses. Pulling account numbers associated with contracted accounts sounds more like it needs a warrant.
hueving 8y ago
Putting the return IP encrypted in the payload breaks NAT (see FTP helpers). You do understand that the IP that the return traffic is destined for has to initially be addressed to the IP of the NAT device, not what the client thinks its IP is, right?
- ikiris 8y ago
  And nothing of value was lost :)
  - hueving 8y ago
    Well except nat doesn't work and the ipv4 internet (which is the vast majority of it) is broken. I wouldn't call the vast majority of the internet something without value.
cornholio 8y ago
Despite the gargantuan effort, you wouldn't actually gain substantial privacy from such a move. True, a single packet wouldn't identify both parties, but an exchange of packets in rapid succession, a TCP handshake or even an UDP stream would immediately leak the same information to any interested hop in the network. Furthermore, eavesdropping for metadata on the line is one of the lesser privacy concerns for most people. What really matters are privacy violations by the providers higher up the stack, where the address of both endpoints must be known to enable communication.

mirimir 8y ago

Yes, this was the key fail. If he'd been careful enough not to leak his IP address, he would arguably have remained free. I was, for example, using VPN services and Tor well before 2008. And I've never been more than a gray-hat hobbyist sort of "hacker". Anyone seriously into criminal activity who didn't reliably hide their IP address was a fool, even then. My point isn't to dump on Rigmaiden. It's just that articles like this contribute to the FUD about privacy being impossible now. The reality is that most criminals have horrible OPSEC. Especially when they're just getting started. And then they're careless about historical connections.

thomastjeffery 8y ago
IMHO, it's less about privacy being impossible, and more about privacy being difficult and expensive.
- mirimir 8y ago
  I don't dispute that it's difficult. But expensive? How so?
  - thomastjeffery 8y ago
    Any decent VPN service has a monthly cost. That isn't trivial for everyone.
    - mirimir 8y ago
      One can get decent VPNs for ~$3 per month. The free version of SecurityKISS is good too, although it's capped at 300MB per day, and offers only 5-10 exit IP addresses.
boomboomsubban 8y ago
What anonymous methods would he have had of buying VPN access? Mailing cash? And if there wasn't stingray technology available, all the IP address could tell them was he was in the San Jose area, which the mail already told them.

LoSboccacc 8y ago

> Likely by using a stingray Article title: “proved”