[Documentation] Encryption Keys, how to find it ?

[tuppulix]

Documentation issues

Anyone know how to take the Encryption Keys to decrypt packet in wireshark using the dissector ? I try all in my knowledge but I'm not having success.

My scenario: I have a Matter plug, and i use the chip-tool to connect with it. Everything work right, but my goal is create the IM for wireshark. And my problem is being able to find the decryption key.

Thank you very much for everyone who will help me in this work.

Platform

No response

Anything else?

No response

[Chapoly1305]

I am digging into the same question, the current progress is reading the code and try to print the key into the log.

For your reference, https://community.silabs.com/s/question/0D58Y0000AhNKGeSQO/how-to-print-the-network-key-of-matter?language=en_US

Let me know if you found anything.

[lxbrz]

Hi, I'm also interested in this. Tried printing and using various keys from all over the matter stack source code, but none of them led to decrypted matter packets in the wireshark dissector.

[lxbrz]

Actually I spend some time investigating this. I was able to verify that I am trying to leak the keys at the correct location in the device firmware (matter stack on zephyr in scope of nrf connect SDK). In matter/src/transport/CryptoContext.cpp if I hardcode the code path taken with CHIP_CONFIG_SECURITY_TEST_MODE (didn't find a simple way to get rid of build error "Warning: CHIP_CONFIG_SECURITY_TEST_MODE=1 bypassing key negotiation...") I am indeed leaking the correct keys from nrf/ext/oberon/psa/core/library/psa_crypto.c in psa_key_derivation_output_key:

psa_key_derivation_output_key:
5eded244e5532b3cdc23409dbad052d2
psa_key_derivation_output_key:
a9e011b1737c6d4b70e4c0a2fe660476

which corresponds to the keys mentioned here matter/src/lib/core/CHIPConfig.h:

/**
 *  @def CHIP_CONFIG_TEST_SHARED_SECRET_VALUE
 *
 *  @brief
 *    Shared secret to use for unit tests or when CHIP_CONFIG_SECURITY_TEST_MODE is enabled.
 *
 *    This parameter is 32 bytes to maximize entropy passed to the CryptoContext::InitWithSecret KDF,
 *    and can be initialized either as a raw string or array of bytes. The default test secret of
 *    "Test secret for key derivation." results in the following encryption keys:
 *
 *              5E DE D2 44 E5 53 2B 3C DC 23 40 9D BA D0 52 D2
 *              A9 E0 11 B1 73 7C 6D 4B 70 E4 C0 A2 FE 66 04 76
 */
#ifndef CHIP_CONFIG_TEST_SHARED_SECRET_VALUE
#define CHIP_CONFIG_TEST_SHARED_SECRET_VALUE "Test secret for key derivation."
#endif // CHIP_CONFIG_TEST_SHARED_SECRET_VALUE

so I know I am definitely leaking the correct keys. The connection does not succeed with this though. Restoring the original code I am leaking proper keys and establishing a matter session, but using those keys packets can still not be decrypted by the dissector. At least I can see the encryped matter packets flying trough the air on my thread network.

Searching further I found this comment by the person that contributed the matter dissector, so I guess decryption for anything incorporating a nonce (i.e. production devices) it is just not implemented.

Also I found that there is an initial version of a dissector upstream in wireshark, but it doesn't support decryption too.

My setup doesn't really matter in this regard, but just in case: I use the nrf52840 dongle as a sniffer. The sniffed device is a custom board being commissioned to an apple home.

[Chapoly1305]

@lxbrz I'm Glad to see someone raised the same question. Here is my fork of dissector; I am using it almost every day to decrypt the traffic and debug. It can only run at Wireshark 4.2.

Here is a brief guide. I hope this can be inspiring. If you still need clarification about any unclear part, I could help answer a few questions that I know the answer.

1. To use CHIP_CONFIG_SECURITY_TEST_MODE, you must ensure both ends enable this. Your device need to compile with it enabled, your controller also need to have it enabled. Otherwise, they will not able to communicate!

2. When using the dissector, ensure you are using and decoding as "Matter-CHIP", not "Matter".

3. The AES keys and Node IDs are used differently during the PASE and CASE phases; there may be different keys you need to note down. If you are concerned about actions such as turning on/off, then you don't need to worry about the part PASE.

4. To decrypt traffic, You must input Node IDs and Encryption Keys. Each conversation will have at least two AES keys (I2R and R2I, where I means initiator and R means responder). To decrypt a message, you will need Nonce and AAD as well. However, if you are able to figure out the Node ID, the dissector can decrypt the message for you. If you don't know the NodeID, you can print the Nonce and AAD, and extract from them.

5. So far, the dissector takes input with different endianness. The AES key shall be inputted in little-endian format, and the Node ID in big-endian format.

[lxbrz]

@Chapoly1305 Thanks a lot! Using your fork I was able to decrypt the matter traffic. This will definitely help us to diagnose and debug connection issues. If someone comes across this, here is what you basically need to do:

1. Compile wireshark 4.2 (branch release-4.2) from source.
2. Compile @Chapoly1305 fork of the dissector and point it to your wireshark source WIRESHARK_SRC_DIR=/path_to_wireshark_source/wireshark make.
3. Copy the resulting matter-dissector.so into $HOME/.local/lib/wireshark/plugins/4.2/epan folder.
4. Modify your firmware to leak encryption keys and node IDs via logs, e.g. for nrf connect that would be:

encryption keys:

diff --git a/ext/oberon/psa/core/library/psa_crypto.c b/ext/oberon/psa/core/library/psa_crypto.c
index 7f0f6ae9e..9a0d41748 100644
--- a/ext/oberon/psa/core/library/psa_crypto.c
+++ b/ext/oberon/psa/core/library/psa_crypto.c
@@ -3931,6 +3931,12 @@ psa_status_t psa_key_derivation_output_key(const psa_key_attributes_t *attribute
         psa_fail_key_creation(slot, driver);
     }

+    printf("psa_key_derivation_output_key:\n");
+    for (size_t i = 0; i < 16; i++) {
+       printf("%02x", slot->key.data[i]);
+    }
+    printf("\n");
+
     return status;
 }

node IDs:

diff --git a/src/transport/CryptoContext.cpp b/src/transport/CryptoContext.cpp
index 8da2897265..310ed07762 100644
--- a/src/transport/CryptoContext.cpp
+++ b/src/transport/CryptoContext.cpp
@@ -172,6 +172,8 @@ CHIP_ERROR CryptoContext::BuildNonce(NonceView nonce, uint8_t securityFlags, uin
     bbuf.Put64(nodeId);
 #endif

+    ChipLogError(SecureChannel, "NodeId: %llx", nodeId);
+
     return bbuf.Fit() ? CHIP_NO_ERROR : CHIP_ERROR_NO_MEMORY;
 }

And of course you also need the thread network key, channel and mesh prefix too. If you got here, you probably know how to obtain these, e.g. by using open thread CLI.