ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Adding decryption keys at "runtime" (dissection time)

From: Bogdan Pavkovic <bogprs@xxxxxxxxx>
Date: Thu, 6 Apr 2017 14:41:15 +0200
Hi Peter, all,

Thanks a lot for the insight regarding this patch.
I will look into details regarding the separate keylog file according to SSL/TLS example.

One question nevertheless:
is there a particular need to write Lua post-disector script
instead of updating the keylog directly from the dissector?

Best regards,
Bogdan

From: Peter Wu <peter@xxxxxxxxxxxxx>
Date: Fri, 24 Mar 2017 12:28:06 +0100
On Tue, Mar 21, 2017 at 05:07:28PM -0400, Michael Mann wrote:
> There are currently two outstanding patches
> (https://code.wireshark.org/review/20585 and
> https://code.wireshark.org/review/20656) that want to modify a UAT at
> runtime for additional decryption keys/information found during
> dissection.  In this case the UAT is providing all of the "static"
> keys, but apparently these dissectors can have some at runtime too.
> Are there currently dissectors that handle such a case so these
> patches can be modeled after those?

The problem with the ZigBee dissector (20656) appears as follows:

 - There is a static (master?) key, configured in UAT.
 - Session keys are encrypted by the master key and transmitted through
   a special message.
 - When a capture is split, this special message will only appear in the
   first capture file and not in the succeeding files. Since the session
   key is not known, these other files cannot be decrypted (only the
   first one can be decrypted).

This (unhandled) result is comparable to the SSL/TLS dissector, if the
TLS handshake messages are missing, the following application data
cannot be decrypted.

> The only solution I can think of is to have a copy of the UAT taken
> (created in the post_update callback of the UAT) and then add the
> "runtime" decryption keys to the copy.  Not the prettiest so I thought
> I'd elicit other opinions.

The UAT was designed to give the GUI full control over the contents, the
dissectors only get a copy of it. Trying to change this might be
difficult. Adding the "runtime" (session) keys to the copy will not help
if the capture file is changed and the UAT is reloaded.

As for how dissectors handle decryption keys, I am familiar with these:

 - 802.11: WEP and WPA(2)-PSK keys can be configured via UAT. These
   secrets normally do not change and UAT works fine here.
 - SSL/TLS: a path to a keylog file can be configured, mappings from an
   identifier to session secrets can be found in this file. Entries are
   loaded at runtime as they are appended (making it usable for live
   captures). UAT would not be usable as it is loaded only once.

One way to solve the ZigBee problem is by using this separate file
approach? The dissector would then read keys from this file (instead of
UAT), a separate Lua post-dissector could be written to append to this
file.

FWIW, for another protocol I also had the need to load external session
secrets during a live capture, these were also loaded from file:
https://github.com/Lekensteyn/wireguard-dissector
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl