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

[Hadriel Kaplan]

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