Hi! Is the file Zigbee Trust Center backup file format documented?
The file has the name backup_TC*.xbee and is generated with BK AT command.
I only know that the contents is encrypted with AES-256-CTR.
The file begins with '\x02\x00\x00\x00\x12\x10…` followed by 2028 bytes of data that looks like random.
The Nonce is 20 bytes starting with ‘\x10\x00\x00\x00’ and the rest 16 bytes look random. This is strange because a nonce is usually less than 16 bytes.
Also, 2028 is not a multiple of 16 (the AES block size).
No it is not documented for the public to see as that would then result in someone being able to decrypt the file.
But it’s already encrypted, so the contents is not available to anyone without the key anyways.
Consider this use-case: I want to replace a legacy XBee coordinator (that predates the backup files) with a new one without reforming the network. Because the network ID is not writable, my only option is to build the backup file by hand, encrypt it with KB key, then restore from it. However because the format is not known, I don’t know how to do that.
If you are using this kind of encryption, then you should be creating a backup file on a regular basis. Using an out of date backup file to restore the network with is not recommended.
But for that to work, I need either:
- An updated firmware that allows to set the network ID
- A hint on how to manually create the backup file
Shulyaka, that is not a function that is going to be made public.
@mvut Can I just ask, why? We’re your customers, we have a use case to be able to replace a coordinator whenever we want.
Security through obscurity alone is discouraged and not recommended by standards bodies like NIST.
Almost anyone with a little bit of time could invest and reverse engineer this backup file. The process itself should be doable. The nouce/IV is added to the backup file, counter on bytes 27-30 (4 bytes) and the IV 31-46 (16 bytes). After that we could just change some known parameter like EE, KY, re-backup and compare the file changes.
Why not just publish the file format and save your customers time?
1 Like
Simply put, for security reasons, Digi opts not to publish that information.
Recommended lecture: Security through obscurity - Wikipedia
Excerpt:
Security by obscurity alone is discouraged and not recommended by standards bodies. The National Institute of Standards and Technology (NIST) in the United States recommends against this practice: "System security should not depend on the secrecy of the implementation or its components. The Common Weakness Enumeration project lists “Reliance on Security Through Obscurity” as CWE-656.
Note for future, if anybody manages to reverse engineer it, let me know.
1 Like