FreeCalypso > hg > themwi-ota-tools
comparison 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 |
comparison
equal
deleted
inserted
replaced
| 8:08e6c475e559 | 9:b6331ae4eea9 |
|---|---|
| 1 The complex logic in smswrap/ota-smswrap-sjs1.c for getting the secured message | |
| 2 into just the right format to be accepted by the card has been copied from | |
| 3 Osmocom Python program shadysim.py - that Python code appears to be the only | |
| 4 existing reference for using the RFM feature of Sysmocom SIM cards. However, | |
| 5 in the process of studying that code and extracting the logic from it, I found | |
| 6 what appeared to be a bug in their code and logic, and sure enough, further | |
| 7 investigation has confirmed it to be a bug indeed, a bug that is tolerated by | |
| 8 sysmoUSIM-SJS1 cards, but not the newer sysmoISIM-SJA2 - hence the test_rfm | |
| 9 function of that Python tool does not work on the new cards. | |
| 10 | |
| 11 When the application message payload is encrypted with any variant of DES | |
| 12 (including the two-key 3DES used on Sysmocom SIMs), the length of the ciphertext | |
| 13 has to be a multiple of 8 bytes - hence if the plaintext length is not a | |
| 14 multiple of 8 bytes, the plaintext needs to be padded. But what should happen | |
| 15 if the plaintext length going into the cipher just happens to be a perfect | |
| 16 multiple of 8 bytes? The correct answer (ought to be obvious) is to apply no | |
| 17 padding at all, i.e., zero bytes of padding. However, the Python code in | |
| 18 shadysim.py adds 8 bytes of padding, and sets the number of padding bytes in the | |
| 19 header to 8. The resulting encrypted message should be considered malformed per | |
| 20 standard specs, but sysmoUSIM-SJS1 cards are liberal in what they accept in this | |
| 21 instance, thus the bug went unnoticed. The newer sysmoISIM-SJA2 cards do not | |
| 22 accept such malformed messages with invalid padding, and it just so happens that | |
| 23 the message generated by the test_rfm function has 40 bytes of plaintext going | |
| 24 into the cipher, perfectly divisible by 8 - hence their test_rfm function fails | |
| 25 on the new cards. | |
| 26 | |
| 27 Our ota-smswrap-sjs1 program accepts an optional third argument after the two | |
| 28 key arguments, selecting the padding mode. The default mode is correct padding; | |
| 29 if the extra padding mode argument is set to 1, our tool replicates the bogus | |
| 30 behaviour of the reference Python code. This bug-compatible mode has been | |
| 31 implemented to make sure that we can generate the exact same packet starting | |
| 32 with data/shadysim-rfm-test (verifying that we have copied the logic correctly), | |
| 33 but it should not be used further beyond these debugging tests. |