FreeCalypso > hg > themwi-ota-tools
view Note-about-padding @ 9:b6331ae4eea9
Note-about-padding added
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Mon, 22 Feb 2021 02:19:43 +0000 |
parents | |
children |
line wrap: on
line source
The complex logic in smswrap/ota-smswrap-sjs1.c for getting the secured message into just the right format to be accepted by the card has been copied from Osmocom Python program shadysim.py - that Python code appears to be the only existing reference for using the RFM feature of Sysmocom SIM cards. However, in the process of studying that code and extracting the logic from it, I found what appeared to be a bug in their code and logic, and sure enough, further investigation has confirmed it to be a bug indeed, a bug that is tolerated by sysmoUSIM-SJS1 cards, but not the newer sysmoISIM-SJA2 - hence the test_rfm function of that Python tool does not work on the new cards. When the application message payload is encrypted with any variant of DES (including the two-key 3DES used on Sysmocom SIMs), the length of the ciphertext has to be a multiple of 8 bytes - hence if the plaintext length is not a multiple of 8 bytes, the plaintext needs to be padded. But what should happen if the plaintext length going into the cipher just happens to be a perfect multiple of 8 bytes? The correct answer (ought to be obvious) is to apply no padding at all, i.e., zero bytes of padding. However, the Python code in shadysim.py adds 8 bytes of padding, and sets the number of padding bytes in the header to 8. The resulting encrypted message should be considered malformed per standard specs, but sysmoUSIM-SJS1 cards are liberal in what they accept in this instance, thus the bug went unnoticed. The newer sysmoISIM-SJA2 cards do not accept such malformed messages with invalid padding, and it just so happens that the message generated by the test_rfm function has 40 bytes of plaintext going into the cipher, perfectly divisible by 8 - hence their test_rfm function fails on the new cards. Our ota-smswrap-sjs1 program accepts an optional third argument after the two key arguments, selecting the padding mode. The default mode is correct padding; if the extra padding mode argument is set to 1, our tool replicates the bogus behaviour of the reference Python code. This bug-compatible mode has been implemented to make sure that we can generate the exact same packet starting with data/shadysim-rfm-test (verifying that we have copied the logic correctly), but it should not be used further beyond these debugging tests.