[pcap-ng-format] Proposal for EPB Hash Option (1 of 4)

[Michael Haney]

The use case (broadly anyway) is for information sharing and preserving privacy. That is, sharing enough but not too much. Think of a telecommunications company or ISP or public hotspot provider sharing data with a law enforcement agency and only sharing the flows of interest to an investigation, not the entire capture. Access to full packet capture data of the suspect needs to be carved out to keep from sharing all of the customer, client, or employee data. So the 'raw' capture file needs to be manipulated somehow. Many suggest 'anonymization' techniques which I would argue don't work. So how does one show that the data captured at the time and place captured hasn't been tampered with? The SHB and IDB are still required parts of the new file, and the epb_hash provides assurance that goes back to the original capture.

Also, if not for data integrity, what then is an individual block hash good for? There are plenty of better (more efficient) ways to de-dupe packets during the analysis phase. 

It's not perfect. If packets are omitted, there's no indication with this option alone. If packets are modified, a malicious user can regenerate the hash. It needs to be protected with a keyed hash or HMAC and encrypted, and key management is a big issue. Hence, DUKPT and the other pieces. Also, forenic best practice is to hash the part and also the whole (e.g., individual files and the whole disk image). But I think many users can still find this option useful. And more useful if the timestamp is included with the packet. 

But I don't think we should get too bent out of shape about it, given that it's optional. Wireshark and other tools don't appear to have trouble ignoring it. I could write it to be epb_alt_hash or something, give it a different code value, and leave the current option defined as it is. I think, though, that the current lack of specificity might be a reason the current option doesn't appear to be in wide use. 

Regards,
Michael


On September 1, 2015 5:56:37 AM MDT, Hadriel Kaplan <the.real.hadriel at gmail.com> wrote:
>On Thu, Aug 27, 2015 at 12:58 PM, Michael Haney
><michael-haney at utulsa.edu> wrote:
>>
>> On Thu, Aug 27, 2015 at 8:57 AM, Hadriel Kaplan
><the.real.hadriel at gmail.com>
>> wrote:
>>>
>>> Do you plan to *use* all of those algorithms?
>>>
>>> Because if not, I'd say cull them down to only what you plan to use.
>>> In fact, I'd suggest we get rid of the ones currently defined in the
>>> draft, but I'll send a separate email about that.
>>>
>>> Also, a small nit, but instead of saying "non-mutable fields" and to
>>> ignore the block type/length and options and all that - just say it
>>> covers "the Packet Data field only, not including padding".
>>>
>>
>> It needs to be more than just the packet data.  I think we need to be
>able
>> to include the timestamp, and at least the snaplen as well to get
>meta-data
>> information about the packet.  Defense against replay attacks.  In
>the
>> course of an investigation, it is just as important when a packet was
>sent
>> as what was in it.
>
>Then it's really a new option, not the current "epb_hash" option. The
>current "epb_hash" one says "The hash covers only the packet, not the
>header added by the capture driver". I don't think it was ever meant
>for detecting malicious modification.
>
>
>> But I don't want to kill the option of adding comments or changing
>the order
>> of options or other reasonable changes to break the hash tests.
>> "non-mutable" might not be the right language there.  But if it's a
>required
>> field in the EPB, it should be required to include in the hash to
>determine
>> if it's been tampered with or not.
>
>I think for your particular use-case, nothing short of hashing the
>entire file with a shared secret (or signing it) will do. Because
>really I don't see how your use-case would be ok with packets being
>removed, or their order changed, or their Interface ID changed, or
>IDBs or SHBs being removed, etc.
>
>-hadriel
>_______________________________________________
>pcap-ng-format mailing list
>pcap-ng-format at winpcap.org
>https://www.winpcap.org/mailman/listinfo/pcap-ng-format
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150901/b20ef536/attachment-0001.html>