On Oct 14, 2011, at 6:03 AM, Ed Beroset wrote: > There is a portion of the code called canonify_unencrypted_header(). In > order to cryptographically process the ASN.1 components of the header, the > data must be canonified. To do this, the dissector must process the pieces > of the header in a particular order no matter what order these were actually > sent. Additionally, the entire BER encoding must be processed, and not just > the data with a [tag, length, value] triplet.
I.e., what gets run through the CMAC algorithm is a bunch of BER-encoded data, in a different order than the order in which the data appears in the header? > I can think of two ways to do this (and indeed, have done it both ways). > First, I can rely on the ASN.1 parser to break things into their respective > fields and then process the components. This approach has two problems. The > first problem is that because the entire encoding must be processed, the tag > and length must be reconstructed which is a bit messy and complex. Could you use #.FN_BODY for each of the fields in question? It looks as if, in the code in question, "offset" would be the offset of the BER tag for the field; once you've called the appropriate code to dissect the field - %(DEFAULT_BODY) might expand to the function body that would have been there without #.FN_BODY, which might be sufficient - "offset" will point past it, so you'd have the offset and length of the entire BER-encoded field, and could, for example, copy it with tvb_memcpy(). If you need to wrap BER encodings for sequences, etc. around the individual fields to make a canonicalized "composite" field, that sounds as if you have to construct a tag in any case. > The more serious problem is that to enable filtering based on crypto results > (e.g. "c1222.crypto_good == true"), the code must also work on packets that > haven't yet been parsed. Why is that the case? "c1222.crypto_good" is part of the protocol tree, and gets put there as part of the parsing process. You can put it into the protocol tree at any point in the parsing process, including after all the other parsing has been done. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
