[dns-operations] IP address encryption: pseudonymization

[Jimmy Hess]

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
other contexts

(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
initialized
        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.

       While capturing;
       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
ID?, finally

                         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.

ALTERNATIVES:

    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,
pcapfilepath_or_processid varbinary(255),
                                                      ipAddressFamily
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
"Correlation ID",
            or  maintain a large number of encryption keys & pick
which symmetric key to use based
            on a hash of the IP.

--
-JH