Jump to content

Recommended Posts

Posted

I am looking to find a way to ensure that I do not directly know the IP addresses of any customers. My initial thought for this is to assign addresses through DHCP (as is currently done) taking the IP addresses, salting and hashing them then applying that hash to to the records. Obviously this would not work for statically assigned addresses.

I am fully aware that this is no way making my customers anonymous. My main goal is to simply ensure that no customer IP addresses are directly known, thus we cannot be compelled to release a customer's address. Also, we would not have any kind of historical record as to which customer had which address in the past (aside from the salted and hashed address within the records).

Is this a feasible option? Are there any programs/protocols currently available to do this?

Posted

You my friend hit on a topic I am working on, but to answer your question, we have nothing today that is "privacy and secure" out of the box, nor data storage models that work one way for authentication without third parties or reversible means put in by design. Doesn't mean we shouldn't implement our own though ;)

Posted (edited)

Because of the simple fact that your traffic needs to reach the customer (that specific customer), you're going to need to know the IP. Period. If you use DNS (DHCP would be when they acquire an IP from you) you can hide it to some extent but not really.

One thing you can do is provide an SSH server with customer-specific accounts that have the following script as their shell:

#!/bin/sh
read

They can then connect to you, forwarding a remote port to their local remote desktop/ssh port. They tell you want port they opened on your machine, you connect to that and do what you must. When you're done they hit the return key in the shell, the script terminates and the ports get closed again. As far as you're concerned you only connected to a port on one of your own machines and as long as the machine you use for this doesn't log anything nobody, including you, will know who you serviced.

Edit: If you create a LiveCD for this machine with a simple Linux on it and you create customer accounts for them on demand as you talk with them in the run-up to this, when you shut down the machine at the end of the day you should be golden. The only downside would be that they would need to know your IP address. Maybe you can do something via Tor hidden services if that's really an issue?

Edited by Cooper
Posted

OK here are the assumptions I'm making from reading between the lines of the original post:

1) your customers connect to your network via some sort of VPN or Dialup connection

2) once connected they get an IP address via DHCP (unless they have paid for a static IP, but that is a different issue)

3) your network's connection to the internet isn't behind NAT, i.e. each IP address handed out by DHCP will be routed to and from the internet.

4) you are wanting to avoid storing any long term mapping between a customer and their IPs.

Working from those assumptions I find myself asking "Do you ever need to log the IP?" Couldn't you simply turn off the logging from your DHCP server.

Of course if there is a further requirement things get more difficult.

5) you are wanting to avoid storing any short term mapping between a customer and their IPs

Here things get tricky as your DHCP server will have a mapping between the customers local MAC addresses and their IPs. One option would be, as suggested, to modify the DHCP server to not store a mapping between MAC address and IP, but between MAC address and a token. While it should be relatively easy to do there are a lot of ways to get it wrong. First of all we'll add another assumption

6) you're using IPv4 subnet for your network

As IPv4 is only 32bits in length then a simple one way hash function of it wouldn't be much use, after all, a normal desktop could generate a mapping that could be used to reverse the process.

Adding in a salt would appear to improve things at first, especially if we make it random and something like 96 bits in length (so a total of 128 bits going into the hash). 128 bits is far to big to prepare a mapping, so problem solved. Unless we make the following, reasonable, assumption

7) your DHCP server will need to keep the salt with the IP to operate.

We can't prepare any mappings before hand so we would have to resort to brute forcing the unknown 32 bits. This gets even worse when you consider that your IPs are actually all going to be within a couple of 8-16 bit subnets. Those sizes are something that a computer can brute force in real time, leaving the salt as no protection whatever.

At this point you either have to consider moving away from dhcp to some custom protocol designed with privacy in mind or move to IPv6 which would let you have, at the very least, a 64 bit subnet. IPv6 also has the added possibility of not needing dhcp. You could simply use radvd to advertise your IPv6 network details and leave the client to generate their own IP address.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...