Hi @mastupristi ,
1. InvCipher() needs to be implemented as below:
Please kindly refer to https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197-upd1.pdf for more details.
2. Regarding the comments between RM and RFC3394 , actually the comments from RM is an index based operation which is also specified in RFC3394:
3. Regarding the source of 'image_enc' , please kindly refer to https://github.com/JayHeng/NXP-MCUBootUtility/tree/master/tools/image_enc/code for details.
Hope that helps,
Have a great day,
Kan
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
- I read. In fact I read that ECB decryption is nothing but the InvCiher described in that paper.
And that's what I tried, unsuccessfully. - OK
- This is what I had already found here:https://community.nxp.com/t5/i-MX-RT/image-enc2-zip-download/m-p/1174943#M10980
These sources cannot be those of the tool distributed with Provisioning tool v6
Look at the command help:
Is now look at the sources:
they do not absolutely match
Please help me! I'll share the otfad_keyblob.bin file with you (it's an "easy" key
test anyway). Can you try to write the sources (or a python script) to unwrap it (try them) and share the code with me?
I generated the file with this command line:
/opt/nxp/MCUX_Provi_v6/bin/tools/image_enc/linux/amd64/image_enc \
ifile=Infile_nopadding.bin \
ofile=Outfile.enc.bin \
base_addr=0x30001000 \
kek=ffeeddccbbaa99887766554433221100 \
otfad_arg=[00112233445566778899aabbccddeeff,0123456789abcdef,0x30001000,0x1c000] \
otfad_ctx_lock=0,0,0,0 \
is_boot_image=0 \
hw_eng=otfad
In the meantime, I delved into SPSDK, and wrote another python script:
import argparse
import sys
from cryptography.hazmat.primitives import keywrap
if __name__ == '__main__':
parser = argparse.ArgumentParser(conflict_handler="resolve")
parser.add_argument("infile", help="input file name")
parser.add_argument("kek", help="kek")
args = parser.parse_args()
with open(args.infile, "rb") as inFile:
wrapped_ciphertext = inFile.read()[:64]
# print(' '.join(['%02x' % x for x in wrapped_ciphertext]))
kek = bytearray.fromhex(args.kek)
print(' '.join(['%02x' % x for x in kek]))
try:
unwrapped_plaintext = keywrap.aes_key_unwrap(kek, wrapped_ciphertext)
sys.stdout.write(unwrapped_plaintext) # you must pipe the stdout of this script to `hd`
except:
print("Failed to unwrap")
sys.exit(1)
But even then it doesn't work
best regards
Max
Trying to approach the problem from a different point, I made other findings that contradict the documentation. Please read all this post
I made a point. To validate my algorithms, it is preferable to test on the "unused" contexts. And it's most likely better to validate a wrapping procedure to get useful information for unwrapping. In fact by wrapping I have both the input data (the plain-text data structure that in unused contexts should be all 0), I have the ciphertext and the KEK key.
I will proceed in the chronological order that I followed.
the command line that was used to create the keyblob used image_enc:
I highlighted the second context that is not used, and all fields are 0
at this point I wanted to try to do the same thing but using spsdk taken from github (nxpimage.py, version 2.0.1, commit 0144584ce8), trying to follow the execution in debug.
I added some print within the code to "see" KEK, plain-text and cipher text
In doing this I realized that the plaintext is not all 0 but has 4 non-zero bytes:
the cipher text is exactly that contained in the keyblob file produced by image_enc. However, the 40-byte plaintext has the last 4 non-zero bytes
the place where these bytes are populated is in the otfad.py file:
The only documentation I have found so far is this:
It is possible to use it for testing but they recommend using random values, and this, as we shall see, contradicts the documentation. In my case zero_fill is a 4-byte array 0-filled while crc is None.
This isn't documented anywhere else (from the research I've done so far), in fact, on the Security Reference Manual it is extensively written that padding must be 0:
I have highlighted the padding bytes, and in red those that are not actually 0.
so other questions to add to the others are related to this:
- what are those four bytes? Where are they documented?
- Are they used by the rom bootloader? And to do what with them? From the code it looks like in all cases they have to do with CRC
- is the documentation wrong?
regards
Max
Current SPSDK contains aes_key_wrap/unwrap present in the spsdk->crypto->symmetric.py
yes I knew that, in fact I wrote my last attempt based on that.
They use this cryptography.hazmat:
the description of the parameters is clear and I wanted to try it too:
import argparse
import sys
from cryptography.hazmat.primitives import keywrap
if __name__ == '__main__':
parser = argparse.ArgumentParser(conflict_handler="resolve")
parser.add_argument("infile", help="input file name")
parser.add_argument("kek", help="kek")
parser.add_argument("bytes", help="bytes", type=int)
args = parser.parse_args()
with open(args.infile, "rb") as inFile:
wrapped_ciphertext = inFile.read()[:args.bytes]
kek = bytearray.fromhex(args.kek)
try:
unwrapped_plaintext = keywrap.aes_key_unwrap(kek, wrapped_ciphertext)
sys.stdout.write(unwrapped_plaintext) # you must pipe the stdout of this script to `hd`
except:
print("Failed to unwrap")
sys.exit(1)
however it does not work.
My keyblob (note that this is working on my EVK using the KEK ffeeddccbbaa99887766554433221100) is like this:
00000000 3f e3 81 f6 e8 a1 47 d2 fa 6c ca 69 53 c6 1c 80 |?.....G..l.iS...|
00000010 1f 4a a3 ea f9 4f 10 f2 90 71 3c 52 5b 39 a6 a4 |.J...O...q<R[9..|
00000020 ba 19 b1 3b b5 48 ae 3f 73 b6 ac c6 60 6a 2a b2 |...;.H.?s...`j*.|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 79 0f 0d c7 d4 4d 61 a1 de 7f f4 09 45 3e fa f0 |y....Ma.....E>..|
00000050 cb 74 01 13 0e 12 12 c0 56 1f bb 89 e3 73 ac 44 |.t......V....s.D|
00000060 11 a2 40 d1 52 1d 7f ec b0 4b 40 d5 16 3b 84 0c |..@.R....K@..;..|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000080 79 0f 0d c7 d4 4d 61 a1 de 7f f4 09 45 3e fa f0 |y....Ma.....E>..|
00000090 cb 74 01 13 0e 12 12 c0 56 1f bb 89 e3 73 ac 44 |.t......V....s.D|
000000a0 11 a2 40 d1 52 1d 7f ec b0 4b 40 d5 16 3b 84 0c |..@.R....K@..;..|
000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000c0 79 0f 0d c7 d4 4d 61 a1 de 7f f4 09 45 3e fa f0 |y....Ma.....E>..|
000000d0 cb 74 01 13 0e 12 12 c0 56 1f bb 89 e3 73 ac 44 |.t......V....s.D|
000000e0 11 a2 40 d1 52 1d 7f ec b0 4b 40 d5 16 3b 84 0c |..@.R....K@..;..|
000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
you can clearly see the 4 blocks, where only the first one has values, and the others are not used (I think they are populated with 0). Padding to 0 is evident. The encrypted part is evidently in the first 48 bytes of the block.
So to the aes_key_unwrap() function I pass 48 bytes and the kek. But despite this it fails to decode.
The full OTFAD keyblob unwrap function is not available in SPSDK. I have created a ticket to add this function for verification purposes. Difficult to estimate when it will be integrated as the team is busy with high priority tasks.
OK, I'm glad that in the SPSDK it was asked to add such a function, but in the meantime can you please review my python source and tell me where I'm wrong?
regards
Max
