[dns-operations] IP address encryption: pseudonymization
mysidia at gmail.com
Mon Feb 26 23:23:10 UTC 2018
On Mon, Feb 26, 2018 at 12:13 PM, Viktor Dukhovni
<ietf-dane at dukhovni.org> wrote:
> Another easy to describe approach, be it at a higher memory cost, is a
> random permutation of 2^32 4 byte elements requires just 16GB of storage.
1* Arguably "bespoke 32-bit block cipher".... and "In-Place
Scrambling" are questionable.
I would have some doubts about the strength of the cipher.
2* It seems like Your PCAP file is corrupt if you are inserting
someone Else's IP addresses
into the file, then you are in a sense creating a "False" or
"Spoofed" PCAP. Someone else's IPs
are going to show up, and if the PCAP gets accidentally processed in
(For example, someone or some tool later used on this file
erroneously thinks this PCAP
has already been "decrypted"), that has potential trouble written
all over it.
Consider something like this, to ensure that each entry in the PCAP file
is protected and Not correlatable to a single user without the key?......
* For each packet captured, maintain a sourceIPAddressCounter
at starting value 0xF0000000 (Non-unicast IP block
240.0.0.0) specific to the
PCAP capture process. Each time a new IP address mapping is
recorded: increment the IPAddressCounter
by one, until the maximum value: 0xFFFFFFFE is reached,
then upon the next increment, reset
the counter to 0xF0000000.
* In place of the IP address within your PCAP: write the
two counter values PENDING saving the mappings.
At this point the "Source" and "Destination" IP fields in the
PCAP file are part of a Token instead of
IP addresses --- the values in the PCAP are counter values
which no longer translate to an IP address,
without also having the Timestamp of that PCAP Record, ID of
that Capturing Process,
and the IP Address you mapped to this triplet.
Also since 0xF0000000.... to 0XFFFFFFFE are in the Class E
Non-IP Address space;
you won't be popping someone else's IP address into a PCAP record.
to save the Index data needed to translate counter values for a
capture record back to an IP address:
* In a second file, named $ipAddressFile:
Write 4 bytes for the IPCounter value, then
Write 8 bytes containing the PCAP timestamp
Seconds and Useconds values,
write 4 bytes representing size, then write
a number of bytes uniquely identifying the capture process
Write a 1-byte value used as a flag to
indicate whether this is the SOURCE IP or the Destination IP address.
write 4 bytes representing the type of address, then
write 8 bytes representing the type of
encryption --- for example RSA, AES256, etc,
write 32 bytes indicating which one of your
encryption keys you chose to encrypt this IP, e.g. Which PGP Keypair
write 4 bytes denoting the length of the ciphertext,
then write the cyphertext bytes
representing the encrypted version of the IP address.
* The encryption method depends on local security requirements.
* Increment the IPCounter value by 1, and if the
counter exceeds 0xFFFFFFFE, then reset the counter to 0xF0000000.
* Repeat the same process with the destination IP address,
using destinationCounter instead of srcCounter, and
increment the destCounter by 1.
Instead of using a mapping, you could use a database that
provides a "Lookup table" for translating an entry in your
PCAP file to strong ciphertext:
CREATE TABLE ipAddressMappings( sourceOrDestination boolean,
countervalue int, pcap_sec int, pcap_usec int,
int, cipherType int, cipherKeyId int, ciphertext mediumblob
IF You require the ability to Correlate records involving the SAME IP address,
then you could optionally:
* Instead of using Encryption; use of separate and
isolated systems requiring authorization to correlate the two files
together could provide higher performance.
* Maintain a temporary in-memory lookup table and re-use
the counter value,
just creating an additional record matching and adding a
or maintain a large number of encryption keys & pick
which symmetric key to use based
on a hash of the IP.
More information about the dns-operations